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1.  Research  Objectives 

The  confluence  of  computers,  communications,  and  databases  is  quickly  creating  a  globally  distri¬ 
buted  database  where  many  applications  require  real-time  access  to  both  temporally  accurate  and  mul¬ 
timedia  data.  This  is  particularly  true  in  military  and  intelligence  applications,  but  these  required  features 
are  needed  in  many  commercial  applications  as  well.  Mjor  applications  are  military  command  and  con¬ 
trol,  avionics  and  weapon  systems  (e.g.,  missile  guidance  system),  and  monitoring  and  decision  support 
systems.  Those  applications  have  at  their  core  requirements  for  managing  and  analyzing  massive 
amounts  of  data  residing  in  many  data  repositories.  Much  of  this  data  has  timing  attributes  such  as  a  par¬ 
ticular  satellite  image  being  valid  for  no  more  than  5  minutes.  Audio,  video  and  images  are  key  types  of 
data  which  provide  increased  value  to  applications,  but  also  increased  challenges.  Driving  such  systems 
are  significant  real-time  requirements  for  managing  thousands  of  objects  and  tracking  them  by  using  a 
global,  intelligent,  and  responsive  multimedia  database  system.  They  have  the  following  characteristics: 

(1)  transactions  with  timing  constraints 

(2)  data  with  temporal  properties 

(3)  distributed  multimedia  data 

(4)  mixture  of  sensitive  and  unclassified  data 

Those  characteristics  lead  to  the  following  requirements: 

(1)  timeliness  and  predictability 

(2)  temporal  consistency 

(3)  integrated  support  of  soft,  firm,  and  hard  deadlines 

(4)  storage,  retrieval  and  synchronization  of  multimedia  data 

(5)  security  enforcement 


(6)  high  reliability 

(7)  scalability  of  solutions 

The  objective  of  this  project  was  to  develop  new  database  system  technology  for  distributed  real-time 
systems  and  to  evaluate  them  in  the  experimental  real-time  database  servers.  Our  focus  has  been  to  dis¬ 
cover  a  set  of  design  principles  for  building  dependable  and  responsive  database  systems  for  time-critical 
applications  and  to  develop  algorithms  to  improve  timeliness  and  predictability  of  such  systems. 


2.  Technical  Approach 

Our  approach  to  achieving  the  objectives  stated  above  has  been  four-fold: 

(1)  develop  a  database  and  transaction  model 

(2)  design  scheduling  algorithms  to  support  timely,  secure,  and  predictable  execution  of  transactions 

(3)  develop  paradigms  and  mechanisms  for  constructing  real-time  database  systems 

(4)  evaluate  the  performance  of  the  algorithms  and  mechanisms  developed  in  this  project  using  simula¬ 
tion  as  well  as  experimental  real-time  database  systems. 

The  first  two  approaches  (modelling  and  algorithm  design)  can  be  considered  as  basic  research  for  setting 
up  foundations  in  this  area.  The  other  two  deal  with  actual  application  of  the  technology  developed  to 
realistic  situations  to  evaluate  their  merits.  Research  results  coming  out  from  the  second  approach  (practi¬ 
cal  issues)  are  then  used  to  revise  the  models  and  algorithms.  This  kind  of  feedback  loop  approach  turns 
out  to  be  very  effective  in  performing  research  in  real-time  systems  area. 


3.  Accomplishments 

3.1.  Schemes  for  predictable  transaction  processing 

There  are  many  cases  of  hard  real-time  database  applications  in  real  world,  such  as  flight  control 
systems  and  missile  guidance  systems,  and  thus  a  flexible  real-time  database  management  system  must 
provide  mechanisms  to  minimize  the  execution  time  variance  of  a  transaction,  making  the  system’s 
behavior  predictable.  We  provide  a  framework  to  classify  different  types  of  transactions  and  to  develop 
processing  schemes  for  each  type  of  transactions  that  can  be  supported  in  predictable  real-time  database 
systems. 

3.2.  New  scheduling  and  concurrency  control  algorithms 

The  algorithms  we  developed  based  on  the  notion  of  dynamic  adjustment  of  serialization  order 
reduce  unnecessary  blocking  and  aborts,  significantly  improving  the  timeliness  of  transactions.  While  the 
original  priority  ceiling  protocol  provides  a  bound  on  transaction  blocking  delay  and  schedulability 
analysis,  they  often  suffer  from  the  problem  of  unnecessary  blockings  due  to  its  conservative  scheduling 
policy.  The  main  reason  for  their  conservatism  is  the  implicit  assumption  that  if  a  transaction  conflicts 
with  other  executing  transaction,  it  is  unable  to  preempt  the  conflicting  transaction.  We  have  shown  that 
real-time  database  systems  could  avoid  unnecessary  blockings  using  the  notion  of  dynamic  adjustment  of 
serialization  order,  resulting  in  improved  performance.  Our  results  will  be  presented  at  the  1 3th  IEEE 
Conference  on  Data  Engineering,  to  be  held  in  England  in  April  1997. 

3.3.  Integrating  security  with  real-time  requirements 

In  principle,  any  system  that  maintains  sensitive  information  to  be  shared  by  multiple  applications 
with  different  levels  of  security  clearance  requires  multilevel  security.  Many  of  those  systems  also 
require  real-time  database  accesses.  Especially  for  DoD/  Navy  applications,  security  is  considered 


essential,  in  addition  to  real-time  requirements.  It  has  been  shown  that  most  conventional  schedulers  are 
not  satisfying  the  security  requirements.  It  is  necessary  to  develop  new  algorithms  for  scheduling  and 
concurrency  control  that  can  ensure  security  according  to  appropriate  models  for  secure  real-time  data¬ 
bases.  Our  algorithms  are  the  first  ones  that  attempt  to  support  both  security  and  real-time  requirements. 

3.4.  Multimedia  data  management 

The  essential  problem  of  multimedia  is  not  of  providing  support  for  individual  media,  rather  support 
for  "synchronizing"  the  otherwise  autonomous  data  transfers  across  computers.  The  issue  of  real-time 
and  synchronization  mechanisms  become  even  more  challenging  in  distributed  systems  as  the  different 
media  streams  may  arrive  from  different  sources.  Our  research  resulted  in  a  systematic  scheme  to  specify 
and  enforce  synchronization  requirements  in  real-time  systems. 

3.5.  Fault-tolerant  scheduling  algorithms 

Existing  fault  tolerance  techniques  for  transaction  systems  are  inadequate  in  a  distributed  real-time 
system  environment  with  respect  to  assuring  system  responsiveness  -  that  no  processing,  communica¬ 
tions,  and  database  transaction  deadlines  will  be  missed.  Since  missing  a  transaction  deadline  can  be 
catastrophic  in  some  circumstances,  the  fault-tolerance  of  these  systems  must  be  addressed.  We 
developed  several  algorithms  to  guarantee  the  hard  deadlines  of  transactions  on  a  multiprocessor  system 
through  statically  scheduling  the  transactions  onto  different  processors  and  using  a  recovery  block 
approach  to  tolerate  processor  failures. 

3.6.  Replication  control  for  critical  information 

As  in  any  other  systems,  critical  data  should  be  replicated  in  real-time  database  systems  for 
improved  availability  and  fault-tolerance.  However,  replication  involves  certain  overhead  to  maintain 
replicated  copies  in  consistent  states,  and  conventional  one-copy  serializability  might  not  be  desirable  for 
its  high  overhead.  We  have  developed  replication  management  algorithms,  based  on  a  weaker  correct¬ 
ness  criterion  called  epsilon-serializability. 

3.7.  Development  of  experimental  real-time  database  servers 

Previous  work  in  real-time  database  systems  has  primarily  based  on  simulation.  Our  research  has 
focused  on  how  current  real-time  technology  can  be  applied  to  architect  an  actual  real-time  database  sys¬ 
tem.  A  real  real-time  database  system  must  confront  many  practical  issues  which  simulation  studies  typi¬ 
cally  ignore:  race  conditions,  concurrency,  and  asynchrony.  By  actually  constructing  a  real-time  database 
server  on  top  of  several  platforms  including  real-time  kernels,  we  have  identified  many  implementation 
issues  and  developed  practical  solutions  to  those  problems. 
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Abstract  In  this  paper,  we  study  the  problem  of  allocating  a  set  of  periodic  tasks  on  a  multiprocessor  system 
such  that  tasks  are  scheduled  to  meet  their  deadlines  on  individual  processors  by  the  Rate-Monotonic  scheduling 
algonthm.  A  new  schedulability  condition  is  developed  for  the  Rate-Monotonic  scheduling  that  allows  us  to 
develop  more  efficient  on-line  allocation  algorithms.  Two  on-line  allocation  algorithms— RM-FF  and  RM-BF 
are  presented,  and  shown  that  their  worst-case  performance,  over  the  optimal  allocation,  is  upper  bounded  by 
2.33  and  lower  bounded  by  2.28.  Then  RM-FF  and  RM-BF  are  further  improved  to  form  two  new  algorithms- 
Refined-RM-FF  (RRM-FF)  and  Refined-RM-BF  (RRM-BF).  both  of  which  have  a  worst-case  performance 
bound  of  2.  We  also  show  that  when  the  maximum  allowable  utiUzation  of  a  task  is  small,  the  wont-case 
performance  of  all  the  new  algorithms  can  be  significantly  improved.  The  worst-case  performance  bounds  of 
RRM-FF  and  RRM-BF  are  currently  the  best  bounds  in  the  class  of  on-line  scheduling  algorithms  proposed  to 
solve  the  same  scheduling  problem.  Simulation  studies  show  that  the  average-case  performance  of  the  newly 
proposed  algorithms  is  significantly  superior  to  those  in  the  existing  literature. 


1.  Introduction 

Rstc-Monotonic  (RM)  scheduling  (Liu  and  Layland,  1973)  is  becoming  a  viable  schedul¬ 
ing  technique  for  real-time  systems.  Through  the  years,  researchers  have  successfully 
applied  this  technique  to  tackle  a  number  of  practical  problems,  such  as  task  synchro¬ 
nization,  bus  scheduling,  joint  scheduling  of  periodic  and  aperiodic  tasks,  and  tran¬ 
sient  overload  (Joseph  and  Pandya,  1986),  (Lehoezky  et  al.,  1989),  (Lehoezky  1992) 
(Ramos-Thuel  and  Stronider,  1991).  (Sha  et  al.,  1986).  (Rajkumar,  1989).  (Rajkuma^ 
and  Lehoezky,  1990),  (Rajkumar  and  Lehoezky,  1990),  (Sha  and  Goodenough,  1990), 
(Sha  and  Lehoezky,  1989),  (Undell  et  al.,  1992).  In  each  of  these  areas,  conventional 
rate-monotonic  scheduling  has  been  adapted  and  extended  to  produce  effective  schedul¬ 
ing  algorithms. 

While  rate-monotonic  scheduling  is  optimal  for  uniprocessor  systems  with  fixed-priority 
assignment,  it  is,  unfortunately,  not  so  for  multiprocessor  systems.  In  fact,  the  prob¬ 
lem  of  optimally  scheduling  a  set  of  periodic  tasks  on  a  multiprocessor  system  us¬ 
ing  either  fixed-priority  or  dynamic  priority  assignment  is  known  to  be  NP-complete 
(Leung  and  Whitehead,  1982).  Hence,  any  practical  solution  to  the  problem  of  schedul¬ 
ing  real-time  t^ks  on  multiprocessor  systems  presents  a  trade-off  between  computa¬ 
tional  complexity  and  performance.  Heuristic  algorithms  have  been  shown  to  deliver 
near-optimal  solutions  with  limited  computational  overhead. 

In  this  study,  we  are  concerned  with  developing  efficient  heuristic  algorithms  for 
scheduling  a  set  of  periodic  tasks  on  a  multiprocessor  system.  The  general  solution 
to  such  a  problem  involves  two  algorithms:  one  to  assign  tasks  to  processors,  and  the 
other  to  schedule  tasks  assigned  on  each  individual  processor.  Two  major  strategies  exist 
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for  ^si^ing  tasks  to  processors:  partitioning  and  non-partitioning  strategies.  In  a  non- 
partitioning  strategy,  each  occurrence  of  a  task  may  be  executed  on  a  different  processor, 
while  a  partitioning  strategy  requires  that  all  occurrences  of  a  task  must  be  executed 
on  the  same  processor.  The  partitioning  strategy  is  often  preferred,  because  relatively 
low  overhead  is  involved  in  the  scheduling  process.  A  scheduling  algorithm  can  also  be 
classified  as  an  on-line  or  off-line  algorithm  according  to  when  the  characteristics  of  the 
whole  set  of  tasks  are  available.  If  a  task  set  must  be  known  completely  a  priori  in  order 
to  apply  an  algorithm,  then  the  algorithm  is  refeired  to  as  being  off-line,  otherwise,  it  is 
said  to  be  on-line. 

Because  real-time  systems  often  operate  in  dynamic  and  complex  environments,  many 
scheduling  decisions  must  be  made  on-line.  For  example,  a  change  of  mission  may 
require  the  execution  of  a  totally  different  task  set.  Or  the  failure  of  some  processors 
may  necessitate  the  re-assignment  of  tasks.  In  these  scenarios,  the  entire  task  set  to 
be  scheduled  may  change  dynamically,  that  is,  tasks  can  be  added  or  deleted  from  the 
task  set.  In  the  following,  we  present  several  on-line  task  assignment  schemes  for 
multiprocessor  systems,  where  each  processor  executes  the  RM  scheduling  algorithm. 

The  solution  to  such  a  scheduling  problem-has  practical  implications.  On  the  one  hand, 
the  real-time  ^plication  domain  is  becoming  increasingly  large.  As  requirements  of 
real-time  support  for  industrial  applications  become  more  sophisticated,  the  employment 
of  multiprocessors  to  meet  computational  power  requirement  seems  inevitable.  On  the 
other  hand,  the  state-of-the-art  of  hardware  technology  makes  multiprocessor  support  a 
reality  for  many  more  systems.  The  scheduling  of  periodic  tasks  on  a  multiprocessor 
thus  becomes  an  urgent  problem  that  needs  to  be  solved.  From  the  perspective  of  RM 
scheduling,  it  has  the  property  that  as  long  as  the  CPU  utilization  of  all  tasks  Ues  below 
a  certain  bound,  all  tasks  will  meet  their  deadlines  without  the  programmer  knowing 
exacUy  when  any  given  instance  of  a  task  is  ranning.  Even  if  a  transient  overload 
occurs,  a  fixed  subset  of  critical  tasks  will  still  meet  their  deadlines  as  long  as  their  total 
CPU  utiliz^ion  lies  within  certain  bound.  The  rate-monotonic  scheduling  has  recently 
been  used  in  a  number  of  applications.  For  example,  it  has  been  specified  for  use  with 
Space  Station  on-board  software  as  the  means  for  scheduling  multiple  independent  task 
execution  (Gafford,  1991).  The  RM  algorithm  wUl  be  built  into  the  on-board  operating 
system  and  is  directly  supported  by  the  Ada  compiler  in  use. 

The  problem  of  scheduling  a  set  of  periodic  tasks  on  a  multiprocessor  systems  has  been 
addressed  in  a  number  of  studies  (Davari  and  Dhall,  1986a),  (Davari  and  Dhall,  1986b), 
(Dhall  and  Liu,  1978).  Typically,  the  task  assignment  schemes  apply  variants’ of  well- 
known  bin-packing  heuristics  where  the  set  of  processors  is  regarded  as  a  set  of  bins. 
The  bin-packing  problem  is  concerned  with  packing  different-sized  items  into  fixed- 
siz^  bins  using  the  least  number  of  bins  (Johnson,  1973),  (Coffman  et  al..  1975).  The 
decision  whether  a  processor  is  full  is  determined  by  a  schedulability  condition.  All 
existing  task  assignment  schemes  are  based  on  the  sufficient  schedulability  condition 
for  uniprocessor  systems  derived  by  Liu  and  Layland  (Liu  and  Layland,  1973)  and  its 
variants  (Dhall  and  Liu,  1978). 

In  all  studies,  the  performance  of  task  assignment  schemes  is  evaluated  by  providing 
the  worst-case  scenarios  for  Na/Nq,  where  Na  is  the  number  of  processors  required  to 
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schedule  a  task  set  by  a  given  heuristic  A,  and  No  is  the  number  of  processors  needed  by 
an  oDtimal  assignment.  Worst-case  bounds  for  the  existing  schemes  are  determmed  by  the 
foltowing  expression:  Na/No.  In  Table  1.  we  suinmanze  the  existing 

heuristic  algorithms  from  the  literature  and  our  new  schemes  with  Aeir  perfonnMce 
bounds.  The  measure  0(f(n))  denotes  the  computation  Ume  complexity  for  scheduling 

a  set  of  n  real-time  tasks. 

Dhall  and  Liu  were  the  first  to  propose  two  heuristic  allocation  algorithms  for  the 
scheduling  problem  (Dhall  and  Liu,  1978).  The  algorithms,  Rate-Monotomc-Next-Fit 
(RMNF)  Ld  Rate-Monotomc-First.Fit  (RMFF),  were  shown  to  h^ye  wors^c^  perfor- 
Lance  bounds  of  2.4  <  ^mnf  ^  2.67,  and  2  <  ^mff  <  4  x2  /(1+2  )  -  2.23. 

Unfortunately,  the  upper  bound  derived  for  RMFF  was  incorrect  due  to  sorne  errors  in 
their  proof.  Furthermore,  their  RMFF  is  off-line,  since  it  requires  that  tasks  must  be 
assigned  in  the  order  of  increasing  period.  ^  ^ 

Davari  aad  Dhall  later  considered  two  other  algorithms  c^ed 
VtUizaion-Factor  (FFDUF)  and  HEXT-FIF-U  (NF-M)  (Davan  and  Dhall.  198fe). 

(Davari  and  Dhall,  1986b).  The  FEDOT  algorithm  sorts  the  ^t  of  ^ksmnojiMj^^ 

Older  of  ..riiivation  factor  and  assigns  tasks  to  processors  m  that  order.  The  f®xr-Frr-M 
alaorithm  dassifled  tasks  into  M  classes  with  respect  to  their  utilizations  Promts  are 
also  classified  into  M  classes,  so  that  a  processor  in  ^s  aemas  k-clwex- 

clusivelv  Their  worst-case  performance  bounds  are  iftppDUF  <  2  and  -KjvF-Af  ^ 
respectively,  where  5„  =  2.34  for  M  =  4.  and  Sm  2.2837  when  M  -  oo. 

Since  the  decision  whether  a  task  can  be  assigned  on  a  processor  is  determined  by 
a  schedulability  condition,  the  nature  and  performance  of  an  allocahon  algonto  is 
determined  in  part  by  the  quality  of  the  condition.  The  worst-case  condition  (or  sufficient 
condition)  of  rate-monotonic  scheduling  has  been  presented  by  Liu  and  Layland  in  their 
seminal  oaoer  (Liu  and  Layland,  1973),  and  the  necessary  and  sufficient  condition  was 
rentit  pXln^seph  and  Pandya,  1986),  (Uhoczky  et  al.,  1989).  While  the  famous 
condition  given  by  n(2^/”  - 1).  where  n  is  the  number  of  tasks  assigned  to  a  processor, 
is  too  con»rvative  in  assigning  tasks  to  processors,  the  necessary  and  sufficient  condmon 

is  too  complex  to  be  used  and  analyzed  in  an  •  .... 

Our  approach  to  tackling  the  problem  is  to  develop  schedulability  condmons  tlmt  exhibit 
good  performance  while  remaining  simple  enough  so  that  the  worst-caw  perfomance 
analysis  is  still  possible.  We  then  develop  several  simple  allocauon  algonthms  using  the 
schedulability  conditions.  In  the  analysis  of  the  worst-case  perform^ce.  we  not  only 
obtain  the  imper  bounds  of  the  algorithms,  but  also  provide  examples  ffiat  show  the 
upper  boundrare  nearly  tight.  In  the  light  of  providing  the  worst-case  peifomance.  our 
analysis  is  non-trivial,  because  the  algorithms  are  more  complex  than  their  bin-packing 
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counterparts,  in  the  sense  that  the  size  of  a  bin  is  unitary  in  bin-packing,  while  the  “size” 
or  utilization  of  a  processor  is  a  variable.  The  value  of  the  variable  is  determined  by 
a  function  that  is  called  the  schedulability  condition.  We  also  derive  the  worst-case 
performance  bounds  of  the  algorithms  with  respect  to  the  maximum  allowable  utilization 
of  a  task.  Finally,  the  average-case  performance  of  the  algorithms  are  shown  to  be 
superior  to  those  in  the  existing  literature  by  simulation  studies. 

The  rest  of  the  paper  is  organized  as  follows:  in  the  next  section,  the  task  model  is 
described,  and  a  new  schedulability  condition  is  presented.  In  Section  3,  a  new  allocation 
algorithm  called  RM-FF  is  designed  using  the  new  schedulability  condition.  Its  worst- 
case  performance  is  analyzed.  An  improved  version  of  RM-FF  is  given  in  Section  4. 
In  Section  5,  we  present  the  Rate-Monotonic-Best-Fit  (RM-BF)  and  its  refined  version, 
both  of  which  are  studied  for  their  worst-case  performance.  In  Section  6,  we  present  our 
simulation  methodology  and  the  results  of  our  experiments.  We  conclude  in  Section  7 
and  indicate  our  future  research  direction. 


2.  Task  Model  and  A  New  Schedulability  Condition 

We  assume  that  the  tasks  to  be  scheduled  have  the  following  characteristics: 

1.  The  requests  of  each  task  are  periodic,  with  constant  interval  between  requests. 

2.  The  deadline  constraints  specify  that  each  request  must  be  completed  before  the  next 
request  of  the  same  task  occurs. 

3.  The  tasks  are  independent  in  the  sense  that  the  requests  of  a  task  do  not  depend  on 
the  initiation  or  the  completion  of  the  requests  of  other  tasks. 

4.  Run-time  (or  computation  time)  for  the  request  of  a  task  is  constant  for  the  task. 
Run-time  here  refers  to  the  time  a  processor  takes  to  execute  the  request  without 
interruption. 

It  follows  that  a  task  is  completely  defined  by  two  ntimbers,  the  run-time  of  the  requests 
and  the  request  period.  We  shall  denote  a  task  r*  by  the  ordered  pair  (Ci,  Ti),  where  C* 
and  Ti  are  the  computation  time  and  the  period  of  the  requests,  respectively.  The  ratio 
Ci/Ti,  which  is  denoted  as  is  called  the  utilization  (or  load)  of  the  task  rj.  All  the 
processors  are  identical  processors  in  the  sense  that  the  run-time  of  a  task  remains  the 
same  across  all  processors.  For  the  convenience  of  presentation,  we  adopt  the  following 
notations:  processors  are  numbered  in  the  order  consistent  with  that  of  allocating  them. 
P  and  Q  are  used  to  denote  processors.  r*,i  denotes  the  Ith  task  that  is  assigned  on  the 
xth  processor;  denotes  the  utilization  of  task  t,,/.  r<  is  used  to  denote  the  itn  task 
where  there  is  no  confusion.  Ui  denotes  the  utilization  of  the  fth  task  on  a  processor  or  in 
a  task  set,  Uj  denotes  the  total  CPU  utilization  (or  load)  of  the  jfth  processor,  r  =  (x,  y) 
characterizes  a  task  t,  where  x  and  y  are  the  computation  time  and  the  period  of  task  t, 
respectively. 

The  scheduling  problem,  which  we  call  the  Rate-Monotonic  Multiprocessor  Scheduling 
(RMMS)  problem,  can  thus  be  described  as  follows; 
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Given  a  set  ofn  tasks  S  =  {r^  =  =  1,2  .,n}.  wAere  each  task  ms 

Characterized  by  its  computation  time  Ci  and  its  period  n  y>hat  is  the  minimum  number 
of  processors  required  to  execute  the  tasks  such  that  their  deadlines  are  met? 

We  sav  that  a  set  of  tasks  is  feasible  if  it  can  be  scheduled  by  some  algorithms  such 
that  all  task  deadlines  are  met.  An  optimal  algorithm  is  one  that  uses  the  minimum 
number  of  processors  for  any  given  task  set.  The  time  to  switch  a  processor  from  one 
task  to  another  is  negligible  compared  to  the  run-time  of  a  task,  and  thus  assumed  to  b 

a  set  of  periodic  tasks  can  be  feasibly  scheduled  on  a  single  processor,  then  Ae 
Rate-Monotoiiic  (RM)  (Liu  and  Layland.  1973)  or  Intelligent  Fixed  Priority  algonAm 
r^erlin  1972)  is  optimal.  The  RM  algorithm  assigns  pnonties  to  tasks  according  to  their 
priority  of  a  tark  is  in  inverse  reiaUonship  to  its  period.  In  other 
«^’a  ^  »Tth  .  Sho^r  period  is  assigned  a  higher  priority.  Ue  ex«ution  of  a 
low-priority  task  will  be  preempted  if  a  high-pnonty  task  arrives.  The  major  result  is 
stated  in  the  following  theorem. 

THEOREM  1  If  a  set  ofn  tasks  is  scheduled  according  to  the  rate-monotonic  a^^ 
then  the  minimum  achievable. CPU  utilization  is  n(2V«  - 1).  Arn  -  oo.  n(2  /-!)-» 
In  2  (Uu  and  Layland,  J973)(Serlin,  1972). 

This  ttMOiem  ensnres  that  a  task  set  can  be  scheduled  to  .^t  fteir  deadlines  if  ^  totri 
utilizaUon  of  the  tasks  is  less  than  a  threshold  ramber,  which  >i8t''en  by  n(  !)• 

where  n  is  the  number  of  tasks  in  the  task  set.  nits  condition-:^,  C./rj  <  n(2 
li  which  is  referred  to  as  the  WC  condiUon,  is  a  worsMase  condmon,  since  there  are  t^ 
Sch  are  feasible,  but  cannot  be  ^«rtmned  ^  f^He  by  t^  WC  con  men 

example,  two  tasks  as  given  by  T,  =  (Ci.r,)  =  (OAl)and  75  =  (C„Ta)- (0.5,1)  are 

infeasMe  accoriing  to  the  WC  condition,  since  El.f./r.  >  2(2*'“  - 1  •  ^ 

!n  fact  feasible  with  the  RM  algoritlun.  There  are  task  se^  however,  ftmac^ly  meet 
the  worsMase  condition.  For  example,  a  task  set  consists  ofn  =  (Ci.T,)  -  (2  -l.i) 

and  r,=  (Cn.T2)  =  (2-2‘/2,2>/t)  with  Er.,Ct/Ti  =2(2'/=-l),  where  any  tncrease 

in  value  of  Ci  or  C2  will  make  the  task  set  infeasible. 

Another  schedulability  condition  was  given  by  Dhall  and  Liu 
while  studying  the  performance  of  their  multiprocessor  heunstics-RMNF  and  RMFF. 

THEOREM  2  Let  =  in  ^  (C„T01t  =  l,2.....n}  be  a  setjrfn  tasks  y^^th  pe^ 

Ti  <  r2  <  •  •  •  ^  r„.  Let  u  =  Ci/Ti  <  (n  1)(2  1).  f  n/  n  - 

9fi  - 1»  then  the  set  can  be  feasibly  scheduled  by  the  rate-monotomc 

uSgort^l  As  n  -  oo.  2llV  u/(7.-l)l-<”-‘>  - 1  -  2e-«  - 1  (DHaU  and  Uu.  ,m). 

This  schedulability  condiUon  requires  that  the  tasks  be  sotted  in  the  orto  of  non- 
decreasing  period,  thus  implying  that  the  task  set  should  be  knora  beforetand.  Some 
of  the  task  sets  that  cannot  be  scheduled  by  ustng  the  WC  conation  can  te  schrfuled 
by  using  this  condiUon,  since  this  condition  takes  advantage  of  the  fi>c>  taste  are 
oJ^  against  non-decreasing  periods.  This  condition  is  referred  to  as  the  IP  condition 

{Increasing  Period). 
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Recently,  the  following  result  was  obtained  (Joseph  and  Pandya,  1986),  (Lehoczky 
et  al.,  1989),  which  contains  a  condition  that  is  both  necessary  and  sufficient.  This 
condition,  referred  to  as  the  IFF  condition,  takes  into  account  of  both  the  computation 
time  and  period  of  a  task. 

Theorem  3  Let  s  =  {r^  =  (C7i,ri)|i  =  1, 2,...,n}  be  a  set  ofn  tasks,  can  be 
scheduled  to  meet  its  deadline  using  the  rate-monotonic  algorithm  if  and  only  if  Li  — 
minutes.  }(Wi(t)/t)  <  1.  The  entire  task  set  S  is  schedulable  using  the  rate-monotonic 
algorithm  if  and  only  if  L  =  max{i<<<„}  Li  <  1,  where  Si  =  {kTj\j  =  1, .. .  ,i;  fc  = 

1, . . . ,  \TilTj\},  Wi{t)  —  Li(t)  (Lehoczky  et  al.,  1989). 


Note  that  the  computation  time  requirement  of  the  IFF  condition  is  data  dependent  In 
the  worst  cases,  it  may  require  more  than  exponential  time  complexity  with  respect  to 
the  number  of  tasks. 

In  the  following  we  present  a  new  schedulability  condition,  which  is  a  sufficient  con¬ 
dition,  and  yet  is  better  in  performance  than  any  existing  sufficient  conditions. 


Theorem  4  Let  E  =  {tj  =  (Ci,T<)|i  =  1, 2, . . .  ,n  —  1}  de  a  set  of(n  —  1)  tasks,  and 
it  can  be  feasibly  scheduled  by  the  rate-monotonic  algorithm.  Among  the  (n  -  1)  tasks, 
the  utilizations  ofO<m<n  —  l  tasks  are  known  to  be  {ui,U2, .  • . ,  tXm}.  and  the  total 
utilization  of  the  rest  of  the  (n  —  m—1)  tasks  is  known  to  be  u,  Le.,  u  =  CifTi. 

A  new  task  Tn  =  (Cn,Tn)  can  be  feasibly  scheduled  with  the  (n  -  1)  tasks  on  a  single 
processor  by  the  rate-monotonic  algorithm,  if 


2[riili(l  +  Wf)i  ^[1  +  -m-  _  1 


ifm  =  n  —  1 
ifm  <n  —  l 


(1) 


This  utilization  condition  is  tight  in  the  sense  that  there  are  task  sets  that  actually  meet 
this  condition. 

The  introduction  of  m  in  the  above  schedulability  conditions  is  to  link  the  two  extreme 
cases  of  m  =  0  and  m  =  n— 1  together.  The  schedulability  conditions  apply  as  long  as  the 
utilizations  of  m  tasks  are  known  and  the  total  utilization  of  the  rest  of  (n  -  m  - 1)  tasks 
is  also  known.  When  m  =  0,  equation  (1)  becomes  CniTn  <  2{l+u/(n— - 1. 
This  condition  is  the  same  as  the  one  given  in  Theorem  2  by  Dhall  and  Liu,  without  the 
restriction  that  tasks  must  be  assigned  in  the  order  of  increasing  period.  The  expression 
in  (1)  provides  not  only  just  one  condition,  but  in  an  effect,  (n  -  1)  conditions.  Most 
significantly,  no  restriction  is  placed  on  the  relative  order  of  the  tasks  that  are  to  be 
scheduled  on  a  processor. 

If  we  minimize  the  expression  U  =  Yll-i  CifTi  over  the  condition  given  in  expression 
(1),  then  the  minimum  is  achieved  when  u<  =  2^/**  —  1  for  i  =  l,2,...,n,  and  U  = 
n(2*/"  - 1).  This  is  exactly  the  condition  given  by  Liu  and  Layland.  In  other  words,  the 
Liu  and  Layland’s  condition  is  a  worst-case  condition  that  is  only  achievable  when  each 
of  the  n  tasks  has  the  same  utilization  of  Uj  =  2^/”  - 1.  If  the  utilizations  of  the  tasks  are 
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no.  the  same,  then  *e  bound  for  Y.U  C./r,  can  be  significantly  higher  Item  n(2‘/”  -1) 
in  some  cases  under  the  new  schedulability  condition.  For  example,  if  ui  =  0.6  and 
-  n  1797  then  the  maximum  utilization  of  a  task  that  can  be  scheduled  together  with 
rgl«n  b,  expression  (1)  is  C„/r.  <  2/1(1  +  u.)(l  +  u.))  - 1  =  0.06 
While  it  is  impossible  to  schedule  a  third  task  on  the  same  processor  if  the  Liu  and 

Lavland’s  condition  is  used.  .  , 

If  we  view  the  schedulability  conditions  for  the  rate-monotonic  scheduling  as  points 

on  a  spectrum,  then  on  the  one  end  is  the  worst-case  condition  by  Liu  and  Lay- 
Ld  and  on  the  other  end  is  the  sufhcient  and  necessary  condition  by  Joseph  and 
Pandva  (Joseph  and  Pandya,  1986),  and  Lehoczky  et  al.  In  the  condition  Ci/Ti  < 
Jnx/n  1 1)  only  the  sum  of  the  task  utilizations  is  taken  into  account.  In  expression 
m  starting  from  m  =  0  to  m  =  n  - 1 .  not  only  the  sum  of  the  task  utilizations  is  ^en 
nto  account,  but  also  the  utilization  of  each  individual  task.  Furthermore,  the  condition 
can  be  expressed  nicely  in  a  formula,  unlike  the  necessary  and  sufficient  condition. 

In  order  to  prove  Theorem  4,  we  need  the  following  two  lemmas. 

LEMMA  1  If  a  task  (Co, To)  cannot  be  scheduled  together  with  a  set  ofn>  l^ks 
^  Try)  ACrt.Tn)}  tv  tkc  rate-rmnotomc  algorithm  and  lo  S  S 
^  <  Tn.  then  (2Co,2Tq)  cannot  be  scheduled  together  with  the  same  set  of  tasks 

{{cZTi)1  (Cz,  Jz),  •  •  • .  (.On, 3’n)}  by  the  rate-monotonic  algorithm. 

Proof:  Let  us  denote  the  task  set  of  { (Co,  Tq) ,  (Ci , Ti), . . . ,  (Cn,  ^)}  ^^di  To ^  — 

<  Tt,  as  E,  and  the  task  set  of  {(2Co,  2To),  (Ci, Ti), . . . ,  (Cn, Tn)}  as  E .  Supj^se 
Aat'for  task  set  E.  the  ith  task  with  1  <  i  <  n  is  the  first  task  to  miss  its  deadline. 
Then  we  claim  that  if  2ro  <  T<.  then  the  ith  task  misses  its  deadline  in  the  task  set  E  , 

otherwise,  task  (2Co,2To)  misses  its  deadline.  ^ 

since  (Ci,  Ti)  misses  its  deadline,  according  to  the  necessary  and  sufficient  condition, 

wc  have 

f(t)  =  (Co\t/To]  +  Ciff/Til  -1 - i-Ci-i\t/Ti-i\  +  Ci)/t  >1, 

for  t  €  S'  =  {bTj\j  =  =  1,2,...,  [Ti/Tj\}^  {To,2To,...,goTo,Ti.2ri, 

Case  1:  2To  <  Ti.  Let  us  examine  the  new  function: 

f'ft)  =  f2Cort/(2To)l +Crft/Til  + - \r  Ci.i\t/Ti-i\-hCi]/tt 

for t  €  5'  =  {kTj\j  =  (y,l,2,. . .  ,i;fc  =  1,2. 

2Ti . 9iri,...,ri-i,2Ti_i,...,gt-iri_i,r<}.  where  Co*  =  2Co  and  To'  -  2ro. 

and  9o'  =  lTi/(2To)J.  «  ,  v  #//*\ 

SiL  CoWri  =  2Cort/(2r»)l  for  t  6  {2To.4T, . 2,0.^}.  we  have  /  (t)  = 

pirVe  (r„2T, . we  claim  that 

2Cort/(2T)1  >  Coft/Tl. 

Since  f  >  To.  we  write  t  =  uiTo  -I-  r,  where  0  <  r  <  To  and  to  >  1.  If  r  --  0,  then 
•2ft/f2To)l  =  2rW2l  >  u>  =  ff/Tol.  If  r  >  0.  then  2rt/(2ro)l  =  2(9/2  +  r/(2To)l 
\q  -H  r /To].  Therefore,  f'{t)  >  j[t)  >  1.  In  other  words,  task  (Ci.Ti)  misses  i 

deadline. 

Case  2:  T,  <  2To.  Let  us  examine  the  new  function: 
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/'(t)  =  (Cl  ft/Til  +  C^  ft/Tzl  +  •  •  •  +  Ci_i  rt/ri-il  +  Ci  \t/T{]  +  2Co)/t, 
fort  €  5'  =  {Tx,T2,..  .  ,Ti_i,Tt,2To}. 

Since  [Tj/Tol  =  2  and  fTj/Til  =  1  for  j  =  1, 2, . . . ,  i,  we  have  f(t)  =  /(i)  >  1.  for 

i6  {Ti,r2» ••  •  >2<_i,Ti}.  Fort  =  2Tb,  f'{t)  =  (2C1+2C2  + - h2Ci  +  2Co)/(2ro) 

=  (Cl  +C2  H - h  Ci  +  Co)/To  =  /(To)  >  1.  In  other  words,  task  (2Co,2To)  misses 

its  deadline. 

Therefore,  the  lemma  is  true.  ■ 

Lemma  1  is  a  very  powerful  lemma,  since  it  implies  that  if  one  task  set  is  infeasible, 
then  there  exists  another  that  is  also  infeasible  with  the  same  task  utilizations,  but  with 
the  ratio  between  any  two  task  periods  less  than  2.  Therefore,  in  deriving  schedulability 
condition,  we  need  only  to  consider  task  sets  where  the  ratio  between  any  two  task 
periods  is  less  than  2. 

The  following  lemma  is  a  reiteration  of  a  fact  that  was  used  implicitly  by  Liu  and 
Layland  to  derive  their  worst-case  condition. 

Lemma  2  For  a  set  ofn  tasks  S  =  {n  =  (Cj,  Ti)\i  =  1, 2, ....  n}  with  fixed  priority 
order,  and  the  restriction  that  Ti  <  T2  <  . . .‘  <  T„  <  2Ti,  the  least  upper  bound  to 
the  processor  utilization  is  achieved  when  Ci  =  2i+i  —  Ti  for  i  =  1,2, ...  ,n  —  1  and 
C„=2Ti~r„. 

Proof:  Let  E  =  {r<  =  (Cu  Ti)\i  =  1, 2, . . .  ,ti}  be  a  set  of  n  tasks  with  Ti  <  T2  < 
<Tn  <  2Ti,  and  Ci,C2,...,Cn  be  the  computation  times  of  the  tasks  that  fully 
utilize  the  processor  and  minimize  the  processor  utilization,  i.e.,  U  -  YJUi 

Suppose  that 


Ci=T2-Ti+A,^>0. 


Let 


CJ  =r2-Ti, 

C2  =  C2  +  A, 

C^=C3, 

Then  CJ, C^, . . . ,  C^  also  fully  utilize  the  processor.  Let  W  =  Th®" 

U-U'  =  (A/Ti)  -  (A/T2)  >  0. 


On  the  other  hand,  suppose  that 
Ci=T2-ri  -A,A>0. 


Let 
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C[=T2-Ti, 
c'  =  C2  -  2A, 
Ci  =  Cz, 


c;  =  Cn. 

Then  again  also  fully  utilize  the  processor.  Let  U'  =  Er=»i<^</2<- 

Then 

U-U*  =  -(A/Ti)  +  (2A/r2)  >  0. 

Therefore,  if  U  is  indeed  the  minimum  processor  utilization,  then 
Ci=T2-Ti. 

Similarly  we  can  show  that 
Ci~Ti+i-Tu  fori  =  2,...,n-l,  and 
c.  =  r.-i:jr,‘Ci  =  2ri-r„. 

Thus  the  lemma  is  proven.  ■ 


Proof  of  Theorem  4:  We  will  obtain  the  expression  in  (1)  through  two  steps:  one  is 
under  the  condition  m  <  n  -  1,  and  the  other  is  under  the  condition  m  =  n  —  1. 

Let  us  first  form  a  new  task  set  called  E,  from  the  task  Tn  and  the  set  of  (n  -  1)  tasks 
=  (CitTi)!*  —  1, 2, ...  ,71  l}»  i.e.,  E  =  {Tilt  =  1,2,...  ,7t}. 

According  to  Lemma  1,  we  can  assume,  without  loss  of  generality,  that  the  periods  of 
the  task  set  satisfy 

Ti/Tj  <  2.  for  t,  i  =  1, 2, . . . ,  n  and 

We  then  sort  the  tasks  in  the  order  of  the  increasing  period  and  rename  them  appro¬ 
priately  such  that 

Ti<T2<...  <Tn  <2Ti. 

Then  according  to  Lemma  2,  the  minimum  utilization  is  achieved  when 


Ci=T2-ri, 


C2  =  T3  —  Tzt 


Cn-X  —  Tn  —  Tn-Xt 
n-1 

Cn  =  Tx-Y^Ci  =  2Tx-Tn. 

<=l 

This  set  of  tasks  fully  utilizes  the  processor,  even  though  there  is  an  unknown  quantity — 
Ci/Ti  in  the  above  conditions,  that  has  yet  to  be  determined.  The  unknown  quantity 
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CijTi  corresponds  to  the  original  CnfTn  before  renaming.  Let  U  =  C/T-  denote 
the  total  utilization  of  the  riew  task  set.  Now  pbserve  that  the  above  conditions  are 
symmetnc  in  the  sense  that  if  we  multiply  2  to  the  computation  time  and  period  of  the 
first  taskn,  then  the  utilization  of  each  task  (and  hence  the  total  utilization  of  the  n  tasks) 
remains  unchanged,  and  the  new  task  set  still  fully  utilizes  the  processor.  Therefore,  by 
applying  the  multiplying  rule  in  no  more  than  n  steps,  we  can  arrive  at  a  new  task  set 
where  r„  is  the  largest  period  among  all  n  tasks,  with  Cr^/Tn  as  the  unknown  quantity 
Furthermore,  we  can  let  Ui  =  Ci/Ti  for  i  =  1, 2, . . . ,  m  and  u  =  C-  /T- 

Case  1:  m  =  n  —  l.  Then  ^t=jn+i  t/-*f 

m 

^  +  Cn/Tn. 


t=l 


i=l 


wte,«  =  cy35  =  (r„.  -  r,)/r,  =  -  l  for  i  =  l,  2 . n  - 1. 

rn?  ‘  ”  c'«/T„  =  (2r,  -T„)/r„  = 

2/  ll<*i  -  1.  But  since  Xi  =  Uj  +  1, 


n-l 


CW/Tn  =  2/  jj  x<  - 1  =  2/ JJ(1  + 1/,)  - 1, 

t=i  t=i 

The  task  sets  that  actually  meet  this  condition  are  given  as  follows: 

Let  Ti  =  <r  >  0,  then  Cj  =  (rm.  Hence  we  have  Tf+i  =  (l+u,)!;-  =  <7 

Ci+i  =  tii+iTf+i  n}=i(l  +uj).  for  t  =  X, 2, . . . , n-2,  and  Tn  =  <Tn”"/(/+ 

«i)  .  C'n  =  - 117=1  (1  +  %)]•  In  other  words,  the  task  sets  are  given  as  ^ 

(Ci,Ti)=  ((TUi.cr), 


(<^2,T2)  =  (crti2(l  -h  Ui),(t(1  +  Ui)), 


n--2  n~2 

j=l  j=l 


n-l 


n— 1 


(Cn,Tn)  —  (<t(2  -  fl  (1  +  Uj)),  <T  fj  (1  +  Uj)). 


J=1 


Case  2:  m  <  n  -  1.  The  utilization  of  task  is  determined 
utilization  is  minimized. 


at  the  point  where  the  total 


^  C-i  /3i  =  ^  Ui  +  u  +  Cn  /Tn , 


i=I 


x=l 


allocating  fixed-priority  periodic  tasks 


217 


where  Ui  =  CijTi  =  (r<+i  -  TiWi  =  Ti+i/r*  -  1  for  i  =  l,2,...,Tri  and  «  - 

=^ri+i/Ti  fori  =  Then  Cn/Tn  =  {2Ti-Tn)ITn 

2j^Zi  ~  proper  substitution,  we  obtain 


m 


n— 1 


=  ^Ui  +  u  -b  2/  JJ  r*  -  1, 

isl  i=l 


Ui 


=  ari“l,/ori  = 


(2) 

(3) 


n-1 


n-l 


i»m-i-l  t=»rt+l 

To  find  the  minimum,  we  need  to  minimize  the  expression  for  U  as  given  in  equation 
(2)  subject  to  the  side  conditions  (3)  and  (4).  This  is  achieved  by  first  forming  the 

Lagrangian 

tn  ^~t 

£,=.[/  +  ^Xi(xi  -  1  -  Vi)  +  M  a;i-(n-m-l)-4 


i=l 


issm-hl 


and  U*n  mintaizing  the  function  i  over  ir's.  Xr's,  and  A.  This  can  be  aaomplishrf  W 
first  taking  the  derivatives  of  Z  over  ir’s,  Aj’s,  and  A,  respectiveiy,  and  then  solving  the 
resultant  equations  after  setting  them  to  zero. 


- —  =  0,/ori  =  l,2,...,m. 

dXi  ^  XiUjZl^j 


(5) 


dL 


=  A- 


dxi  ”  XiUU^i 


=  0,  for  i  =  tn  4- 1,  m  +  2, . . . ,  n  —  1. 


(6) 


—  =  ari-l  -  Ui  =  0,/ori  =  l,2,...,m. 
dXi 


(7) 


dL 


n-l 


££  --  ^  li  -  (n  -  m  -  1)  -  U  =  0. 
iscyn-rl-l 


(8) 


In  the  following  we  show  how  the  above  equations  can  be  solved  to  obtain  the  final 


results. 


'fiy  multiplying  the  (n  -  1)  equations  in  (5)  and  (6)  together  and  manipulating  the 
resultant  equation,  we  get 
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n-l 


IT  \(n-m- 


2(n-l)/n 


^  -  (9) 

By  substituting  the  rij-=i  in  (5)  and  (6)  by  that  in  (9)  and  solving  for  xj’s,  we  have 


Xi  = 


Ai 


•,/or  i  =  1,2, . .  .,m. 


(10) 


A(”*+i)/«  +  ljni  + 2, . . . ,  n  —  1. 


Since  =  1  +  ui,  we  have  from  (10)  that 


•,fori  =  1,2,..., 


m. 


(11) 


(12) 


By  multiplying  the  m  equations  in  (12)  together  and  manipulating  the  resultant  equa¬ 
tion,  we  get  ^ 


m 


(13) 


=  t"  -  “  6»">  W  Md  x,  =  (n-m- 

1) - - frpm  (11),  we  have 


■TT 

-  m  -  1)]«. 

i=t  ^ 


(14) 


For  convenience,  we  let  A  =1-1 - Jt —  and  KJ  —  FT”*  /i  j. \  wr.i. 

/'i‘j\  «  A  nA\  *  lu  ,  ^  -  llt=i(H-w»).  With  equations 

(13)  and  (14)  together,  we  can  solve  for  A: 


A  = 


V^n-m  • 

With  equations  (12),  (14),  and  (15)  together  we  can  solve  for  Af’s: 
2 

~  (H-Ui)VA”“”*-i’  =  1»  2,  • . . , 

Then  we  have 

n^.= 


(15) 


m. 


t=i 


m— l)m  * 


(16) 


^  Now  we  aie  ready  to  solve  for  ari’s.  With  equations  (11),  (15),  and  (16)  together 


we 
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2V”(n^i  __  A  for  i  =  TH+ l,ni  +  2, ...  ,n  —  1. 

~~  \(,Tn.+l)/n 


(17) 


Sin«n  =  l  +  «ifo”=l’2 . 


c. 


-1  = 


-1. 


In  other  words,  if 

Q  _ _ 2 _  -  _ 

^  '  ns=l(l  + 

tel.  the  new  task  set  can  be  feasibly  scheduled  by  the  Rate-hlonotonic  algorithm. 
As  n  oo.  we  have 

m 


j _ 1  — >  2e~'^l TT(^  ^ 

(VAn-rn^  fJl 


Ue  task  sets  that  actually  meet  this  condiU™  ate  given  “  ^  . 

U,r.  =ff  >0.thenC,  =<TU.-  Hence  we  have  r,«  =  (H-Ui)T.  - 
xw  tr  _  /TM.^v  n*.  ,(1  +  t^i).  for  *  =  1,2,. . .  ,m  -  1,  Tm-n  —  *>»•»»»» 

=  -.rr=  /hr.  =  Ct  =  ^  = 

L  other  words.  wS  e  as  a  variable,  the  task  sets  are  gtven  as 
(Cl, TO  =  {<rui,<r), 

(C2,T2)  =  (<7U2(1  +  “l)' 


m— 2 


(C 


i=i  j=i 


m-l 

(c„.T„) = (<.»«  n  (1 + n 


m-l 

H' 

i=i 


m 

(C„.,i,T„h.i)  =  (e(A  -  1)  11(1  +  Uj).<r  11(1  +  uj)), 

i=i  i=i 
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(^n-2, 


T„.2)  =  (<t(A  -  JJ(1  +-Wj),<TA’‘-3-m 

j  =  l 


m 


11(1 +“j)). 

i=i 


m 


-  JI(1  + 


(C^n.Tn)  =  ((r(2  -  VA”-'”-i),<rA"-'”- V). 


3.  The  Design  and  Analysis  of  Rate>Monotonic-First-Fit 

The  problem  of  assigning  tasks  onto  the  minimum  number  of  processors  very  closely 
resembles  the  bin-packing  problem,  in  which  items  of  variable  sizes  are  packed  into  as 
ew  bins  as  possible.  Therefore,  many  of  the  bin-packing  heuristics  can  be  adapted  to 
assign  tasks  to  processors.  However,  the  key  difference  between  the  bin-packins  nroblem 
and  the  RMMS  problem  is  that  the  “size”  or  utilization  of  a  processor  is  nM^always 
umtaty,  but  rather  it  is  a  variable  whose  values  are  determined  by  the  scheduIabiliL 
wndition  Among  the  many  bin-packing  heuristics.  First-Fit  has  the  nice  property  of 
temg  on-line,  simpte,  Md  efficient.  Its  worst-case  performance  is  near  to  the  that  of  an 
optimal  algorithm  (Coffman  et  al..  1975)  (First-Fit  has  a  worst-case  tight  bound  of  1.7 
while  any  on-line  bin-packing  heuristic  must  have  a  worst-case  bound  of  at  least  1  S'?/;’ 
SeeCCoffinan  etal..  1975)  for  deuils).  We  will  Fim-H,  ,  Jgf  “X  f  b 

to  prot^ors  in  onr  new  scheduling  algorithm,  called  Rate-Monotoitic-Fintt-Ht  (^-FF) 

tliffetent  from  Dhall  and 

m  RM-FF  algorithm  is  deigned  as  follows:  let  the  processors  be  indexed  as  fi  i», 
widish  OM  initially  m  the  idle  state,  i.e.,  with  zero  utilization.  The  tasks  {n  n  '  t 
will  be  scheduled  in  that  order.  To  schedule  r„  find  the  least  j  such  that  tik  r  tOKthr/ 
with  ^1  the  t^s  that  have  been  assigned  lo  processor  Pj,  can  be  feasibly  "robedtiled 
l^^ing  to  the  new  schedulability  condition  for  a  single  processor,  and  assign  tmk  ti 

To  ^scrite  RM-ro  in  a  more  algorithmic  format,  we  let  by  and  u.  deiote  the  number 

of  1“''°  ®  processor  Py  so  far  and  the  total  utilization 

of  the  by  taste,  respectively.  Note  that  m  denotes  the  utilization  of  task  t-  and  « 
denotes  the  utilization  of  the  ttit  task  assigned  on  processor  Py.  »  u  ti,j 

Rate-Monotenie-First-Flt  (RM-FF)  anput:  task  set  S;  Output-  m) 

(1)  t  :=  1;  m  :=  1;  t'  ■  J 
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(2)  i  :=  1:  While  K  >  ~  ^  ^  *’ 

(3)  kj  :=  kj  + 1;  Uj  :=  u/+  «»;  //  Assign  task  n  to  Pj 

(4)  If  (j  >  m)  Then  m  =  j\ 

(5)  i  :=  i  +  1; 

(6)  K(i>n)  Then  Exit  Else  Goto  2; 

When  the  algorithm  terminates,  m  is  the  number  of  processors  required  by  RM-FF  to 
schedule  the  given  set  of  tasks.  The  RM-FF  algorithm  has  the  following  distinguished 
property:  no  incoming  task  is  assigned  to  an  idle  processor  unless  it  cannot  be  assigned 
to  any  processor  that  has  already  been  assigned  some  tasks.  We  will  implicitly  use  this 
property  throughout  the  analysis.  In  order  to  obtain  the  worst-case  bound,  we  need  some 

lemmas. 

Lemma  3  Ifn  tasks  cannot  be  feasibly  scheduled  on  n  —  1  processors  according  to  RM- 
FF,  then  the  total  utilization  of  the  n  tasks  is  greater  than  n/(l  -I-  2^2)  =  n(2  '  -  1). 


Proof:  The  proof  is  by  induction. 

yj  _  2,  Suppose  til  and  U2  are  the  utilizations  of  two  tasks  which  cannot  be 
scheduled  on  aprocessor  according  to  the  new  condition,  i.e.,  U2  >  2(l-l-ui)“^  -1.  ^en 
ui  +U2  >  “1 + 2(1  +  wi)“^  “  To  find  the  minimum  of  f{ui)  =  ui  +  2(1  -1-  ui)"^  - 1, 
we  take  the  derivative  of  the  ftinction  /(ui)  and  solve  for  ui.  The  minimum  of  f{ui) 
is  achieved  when  ui  =  (2^/^  _  i).  Therefore  Ui+U2>  2(2^/^  _ 

(2)  Suppose  the  lemma  is  true  for  n  —  k,  i.e.. 


-  1),  (>*) 

i=l 

where  U{  is  the  utilization  of  task  Ti. 

When  n  =  fe  +  1.  the  (fe  l)th  task  cannot  be  scheduled  on  any  of  the  k  processors, 
i  e  tii  -1-  Ufc+i  >  2(2^/*  - 1),  where  1  <  t  <  fc.  Summing  up  the  k  equations  yields 


(19) 

isl 

Multiplying  (/:  —  1)  on  both  sides  of  equation  (18)  yields 

(Jfc-l)^«i>(*-lW2*'“-l)  <20) 

Adding  up  equations  (19)  and  (20)  and  dividing  the  new  equation  on  both  sides  by  k 
yields  Uj  >  (fc  +  1)(2^/^  -  1).  Therefore  Lemma  3  is  proven.  ■ 
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Lemma  4  In  the  final  RM-FF  schedule,  among  all  the  processors  on  which  n  >  c  >  1 

m'A  o  ;«J  rtan  or  «jm( 

/o  c(2  —  1).  ^ 

Proof:  lemma  is  proven  by  contradiction.  Suppose  there  are  two  processors  each 

of  which  has  a  utilization  less  than  or  equal  to  c(2i/(‘'+i)  -  l) ,  and  let  Pi  and  Po  be 
the  two  processors,  and  rii  be  the  number  of  tasks  assigned  to  processor  P<  with  n  -  >  c 
and  i  =  1,2.  Let  Uij  be  the  utilization  of  the  jth  task  that  is  assigned  to  processor  Pi 
for  *  -  1, 2  and  1  <  i  <  n^.  Then  -  1)  for  i  =  1, 2. 

If  there  exists  a  task  rj.*  such  that  ua.*  >  (2  V(c+i)  -  l)  for  i  <  a;  <  ’  Oi&n  there 
exists  a  task  with  a  utilization  U2,3,  <  (2  V(e+i)  _  i),  since  there  are  totally  n,  >  c  tasks 
on  proctor  P,  and  -  1).  where  a:  y  and  1  £  p  | 

Other  words,  there  exists  a  task  T2,z  on  processor  P2  satisfying  uo  ,  <  —  i  ^ 

where 2 e  {1,2,..., 712}-  »  -  ^ 

Since  uij  +U2,*  <  -  1)  +  _  1)  _  ^  l)(2V(c+i)  _  jx 

T2,z  can  be  assigned  on  processor  Pi.  This  is  a  contradiction  to  the  way  RM-FF  assigns 
tasks  to  processors.  Therefore  the  lemma  must  be  true.  g 

Theorem  5  Let  M  and  Ko  be  the  number  of  processors  required  by  RM-FF  and 
the  minimum  number  of  processors  required  to  feasibly  schedule  a  given  set  of  tasks 
respectively.  Then  JNT  <  [2  +  (3  -  ^  2)]N^  + 1 «  2.33iVo  +  1 

In  order  to  prove  the  above  bound,  we  define  a  weighting  function  that  maps  the 
utilization  of  a  task  into  the  real  interval  (0, 1]  as  follows:  ^ 

flu)  =  /  0  <  u  <  a 

a<u<l  ’ 


where  o  =  2(2^/®  —  1). 

Lemma  5  If  a  process^  is^rigr^ommber  of  tasks  {n.Th . t„}  srith  utilizations 

>  tig  ^  ^  ti„.  then  ^i-i  f{ui)  <  l/o,  where  a  =  2(2^1^  —  1). 

Proof:  If  ui  >  o,  then  U2  <  a,  since  a  «  0.52.  y)"  ,  /(«,•)  =  f(u,)  4.  V"  fft,.  ^  - 
|+Er.a«</a  <  l+(l-a)/n  =  1/a.  Ohe^ire  < 

Lemma  6  Suppose  tasks  are  assigned  to  processors  according  to  RM-FF.  If  a  processor 
IS  assigned  n  >  2  tasks  and  >  2(2^3  _  1).  then  ,  Hud  >  1  where 

ui>n2>...>unare  utilizations  of  the  n  tasks  {n,  rj. . . .  ,1^}  t^^are  assigned  to 
it* 

Proof:  Since  m  >  2(2'/3  -  1),  we  either  have  u,  >  o  or  u,  <  o  If  u,  >  e 

to  to®  »f  weighting  flinction;  Othenrtse; 

2-tt=i  /(tig)  =  Z).=i  tii/a  >  1,  where  a  =  2(2^/^  _  » 
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r  t Thonrpin  5-  Let  S  =  (ti.to,  . .  - , Tn}  be  a  Set  of  n  tasks  with  their  utilizations 
E  Jr.  J  =  r../(u<).  B,  Lemn.a  5,  .  <  iV,/a. 

P,  among^^/i  W««ors.  Ut  us  divide  d«se  piocesaors  into  two 

different  classes: 

(1)  Processors  to  each  of  vdiich  only  one  task  is  assigned.  Suppose  there  are  m  of  them. 

m  Processors  to  each  of  vrhich  two  or  more  tasks  ate  assigned.  Let  nj  denote  the 
nombw  of  processors  in  this  class.  According  to  Lemina  4,  there  is  at 
lessor  whose  utilization  in  the  RM-FF  schedule  is  less  than  or  equal  to  a  - 
2^2^/^  —  1)  •  Therefore  n2  <  1* 

Obviously.  L  =  m  +  n2.  For  each  of  the  rest  N-L  processors.  Zj  fM  ^ 

j  ranges  over  all  tasl«  ^  ni(2'^^  —  1)  according  to  Lemma  3.  Since 

For  the  processors  in  class  (1).  linT  ft,,  \  ^  roi/2  -  /n 

fCu  )  <  1.  it  holds  that  Ui  <  o.  Therefore.  Ei*i/(^)  >  "^^2  ;  ^ 

Mo7eoiir!lc^rding  to  Umma  4.  there  is  at  most  one  task  whose  utilization  is  less  thm 
at  tft  _  1  \  In  the  optimal  assignment  of  these  tasks,  the  optimal  number  No 
Tf  ™2used  cL^t  be  iL  than  n.A  >  n./2.  «nce  possibly  with  one 

««ption.  any  diree  tasks  among  these  tasks  caimot  be  “■  PK»^s<>f- 

Now  we  are  ready  to  find  out  the  relationship  between  N  and  Nq. 


>  (iV-L)+ni(2^''*  ~l)/a-iV--ni -n2  +  ni(2‘/*  l)/o 
=  iV  -  ni(l  -  (2^/^  -  l)/ol  -  ^2 

>  N-  2JVo[i  -  (2^/^  -  1)H  -  ^2- 


Since  f(ui)  =  ^  ^o/a  by  Lemma  5. 

No/a  >  AT  -  2Aro(l  -  (2^^^  "  D/®)  -  «2  >  N  -  2Aro[l  -  (2^=*  -  D/a]  -  L 

Therefore,  N  <  (2  +  (3  -  2^^D/a\^o  + 1* 


Havine  proven  the  upper  bound  for  RM-FF.  we  construct  a  number  of  task  sets,  e^h 
of  wS  when  schedSed  by  RM-FF.  requires  nearly  the  “Pf' 
of  orocessors  This  theorem  also  serves  as  an  counter  example  for  the  claim  that  RhOT 
“s  S^Lnded  by  2.23  in  (Dhall  and  Liu,  1978).  Since  the  lasite  m  each 

the  sme  utilization,  and  to  show  4  >" 

ih  “a^of  condLm-C«/r„  <  2/  ^=7(1  +  «t)  - 1-  No  ■" 

with  this  replacement. 
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Theorem  6  Let  N  and  Nq  be  the  number  of  processors  required  by  RM-FF  and 

the  minimum  number  of  processors  required  to  feasibly  schedule  a  given  set  of  tasks 
respectively.  Then  ■'  ' 

^M-FF  —  N/N'o  >  2.2833 . . . 

A/o— »oo 


Proof:  TTie  proof  consists  of  constructing  task  sets  such  that  RM-FF  exhibits  the  woist- 
case  perfonnance  when  it  is  used  to  schedule  them. 

Let  n  -  120k  with  A;  >  1.  The  task  set  is  given  as  follows:  first  n  tasks  are  given 
each  of  which  has  a  utilization  of  ui  =  2i/3i  _  i  +  e  «  a  small  positive  number 

For  our  construction,  it  suffices  to  let  c  <  0.00006.  Next  come  n  tasks,  each  with  a 
utilization  of  U2  —  2  /  - 1  +  c.  Finally,  there  are  2n  tasks,  each  with  a  utilization  of 

tta  =  2^'^  - 1+  e. 


When  iWs  task  set  is  scheduled  by  RM-FF,  the  first  n  tasks  will  use  In/30 1  orocessors 

T  r  '  +  ‘  ^  -  *  +/M/30}-»  -  1.  The  L 

up  Ln/4J  processors,  since  2^^  -1  +  €>2{1  +  {4(2V5  - 1 +e)]/4}-*  - 1.  The  last  2n 
tasks  will  take  up  2n  processors  for  similar  reason.  Thus,  the  total  number  of  processors 
allocated  for  this  task  set  by  RM-FF  is  JV  =  2n  +  [n/4j  +  [n/30J  =  274A;. 

For  the  optimal  schedule,  each  processor  is  assigned  four  tasks  and  a  total  of  n  proces¬ 
sors  is  required.  More  specifically,  for  each  processor,  it  is  assigned  two  tasks  each  with 
a  utilization  of  (2^/2  _  1  +  g),  one  task  of  (2 VS -l+e),  and  one  task  of  f2 V3i  _  1+ 
since  2(2^  ~  1  +  e)  +  (2^31  -  1  +  e)  <  1  for  e  <  0.00006.  There¬ 

fore,  No  —  n  —  120 A:.  The  schedule  by  RM-FF  and  the  optimal  schedule  are  given  in 
Figure  1.  * 


Ca)  RH>PF  Schedule 


(b)  Opciaal  Schedule 


U3 


U3 


Figure  L  RM-FF  vs.  Optimal  Schedule. 

Then  the  asymptotic  bound  of  RM-FF  satisfies 

=  274fe/(120J!:)  >  2.2833 . . . 


Theorem  6  shows  that  the  number  of  processors  required  by  RM-FF  to  schedule  some 
task  sets  can  be  2.283  times  that  of  the  optimal  number  of  processors.  Since  Theorem  5 
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Table  2.  Tbe  Worst-Case  Performance  Bounds  of  RM-FF  under  a 


a 

">U.4142" 

<  U.4'n2~ 

<  u.luy’i 

2:is 

■  TSZ 

1775 

rss 

1.63  1  T57  1 

ensures  that  the  number  of  processors  required  by  RM-FF  to  schedule  any  given  task 
set  cannot  exceed  2.33  times  that  of  the  optimal  numbo'  of  processors,  we  conclude  that 
the  bound  of  2.33  is  almost  tight.  Note  that  the  lower  bound  of  2.283  may  be  improv^ 
or  pushed  since  the  above  construction  does  not  guarantee  that  the  bound  of  2.283  is 
indeed  the  worst-case  lower  bound. 


4.  The  Design  and  Analysis  of  Refined-Rate-Monotonic-First-Fit 

The  bounds  for  RM-FF  were  drived  under  the  general  assumption  that  the  utilization 
of  a  task  can  taire  any  value  between  zero  and  one.  If  the  utilization  of  a  task  is  small 
compared  to  the  processing  power  of  a  processor— -a  very  realistic  assumption  considering 
the  state-of-the-art  hardware  technology — ^we  show  that  the  worst-case  performance  of 
rM-FF  can  be  significantly  improved. 

Let  a  be  the  maximum  allowable  utilization  of  a  task,  i.e.,  a  =  maxi{Ci/ri}.  Then 
we  have  the  following  theorenu 

Theorem  7  Let  N  and  No  be  the  number  of  processors  required  by  RM-FF  and 
the  minimum  number  of  processors  required  to  feasibly  schedule  a  given  set  of  tasks, 
respectively.  Further  let  a  «  maxi<<<n{«i},  Ifoi  <  -  1,  then 

^  (c-f  l)(2V(2+c)_i)» /<»•  c  =  0, 1, 2, . . . 

When  c  -  oo.  (c  +  l)(2V(2+c)  _  Then  ^  Vln2.  The  upper 

bounds  of  RM~FF  with  regard  to  a  are  given  in  Table  2  for  a  few  values  of  a. 

Proof:  For  any  set  of  n  tasks,  let  ^  utilization  of  the  task  set 

According  to  RM-  FF,  if  a  <  —  1,  then  each  processor  must  be  assigned  at  least 

(o-Fl)  tasks  since  a(c-H)  <  (c-f  -1),  except  possibly  for  the  last  processor. 

According  to  Lemma  4,  among  all  the  processors  to  each  of  which  at  least  (c-f  1)  tasks 
are  assigned,  there  is  at  most  one  processor  whose  utilization  is  less  than  or  equal  to 
(c-H)(2»/<2+‘'>-l),  for  c  =  0, 1, 2, . . .  Since  (iV-2)(c-f  _ i|  <  <  jVq, 

When  c  -*  oo,  (c  -f  _!)—♦.  In  2.  Then  * 

It  is  clear  that  if  oc  is  small,  RM-FF  performs  well.  However,  its  performance  degrades 
rapidly  when  a  >  0.4142.  If  we  can  find  a  better  way  to  schedule  the  tasks  with  large 
utilization,  and  use  the  RM-FF  to  schedule  the  tasks  with  small  utilization,  then  the 
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overall  performance  of  the  combined  algorithm  Will  be  ^ 

to  develop  a  new  allocation  algorithm  that  is  based  on  motivated 

I.  is  called  the 

RRM-FF  first  divides  the  processors  into  Te T  (RRM-FF). 

there  is  a  semi-infinite  number  of  processors  IheiUtT  ®»ch  group 

groups  according  to  their  utilizations  such  that^ks  witMnt'^'^®^ 

same  group  of  processors.  Let  the  processors  in  AsTfi  »  assigned  to  the 

indexed  as  Pr.  Pz . and  processLTAr^L*!^”^^^^  5?'^  ‘^®  ^  g«>«P)  be 

as  Qi, Q2, ....  with  each  one  initially  in  the  idle ^  ^  *"‘*®*®^ 

group  if  its  utilization  is  larger  than  1/3  i  -  «.  ?  btlongs  to  the  first 

second  group.  The  tasks  {ti.ts  t  \  win  L  VS.  otherwise  it  belongs  to  the 
RRM-FF  first  identifies  the  task  group  it  beIon«^“^l*"  schedule  n. 

task  n,  together  with  all  the  tasks  thaf  have  been  assimld^m”  ^  *** 

groups,  respectively.  “  *e  first  and  second  processor 


*  I—  1;  Trip  :=  1;  ttiq  :=  i; 

If  (ui  >  1/3)  Then  { 

j :—  1;  feasible  :ss  False:  //  ti<  >  l  u-  -  • 

Repeat  '  ^  assigned  to  processor  group  P 

nif “  2)Th«n  feasible:s'n.ie 

“  V L"* raax/^niin J Cinfgj  +  Cinasc  <  ITL  /T’  .  t'P  \  r\rx  trm  #  *  ^ 

+  Cmax  £  2]n^)  Then  feasible^  IVue  *"*"  ^  mwt/^'minl 

^  Elsej:=J  +  i; 

Until  (feasible); 

*  ^Pj  +  1;  =  U>j  +  U,;  If  (;  >  mp)  Then  mp  :=i; 


(1) 

(2) 

(3) 

(4) 

(5) 

(6) 

(7) 

(8) 

(9) 

(10) 

(11) 

(12)  } 

IL  V  1*0  j ,  7  :=  y  + 1; 

1.  I  *X|x*2  Vtrft* 

05)  ^  *,  j  :=  +  :=Cr^j+u<;BO>mci)nen  mg  := 

07)  .•  :=  .•  + 1:  If  (i  >  „)  ^  ^ 

When  the  algorithm  returns,  m  is  the  total  number  nf 
a  given  set  of  tasks.  Note  that  the  grouping  of  tasks 

algorithm  is  on-line.  Also  note  that  Ae  MhedulahinL  *  and  cleariy  the 

tasks  in  the  first  group  is  the  IFF  condition  Sinre  ^  condition  used  for  scheduling 

any  p«K:««>r  to  to.  L  ““  '*  “***"«*  » 

group  r.  uie  IFF  schedulability  test  can  be  reduced  to 
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Table  S.  The  Wbrsl-Case  Performance  Bounds  of  RRM-FF  under  a 


QC 

<  0.414Z 

<  u.z5ytf 

-nngsz" 

<UT4ffr 

is: 

- ZOO 

roz 

1.76 

lU 

1.6^ 

i;47' 

just  two  comparison  operations.  Therefore,  the  overall  time  complexity  of  the  RRM-FF 
algorithm  is  still  O(nlogn).  The  worst-case  performance  bound  for  RRM-FF  is  given 
in  Theorem  8.  The  following  lemma,  recently  obtained  in  (Burchard,  1994),  was  tey  to 
the  proof  of  the  upper  botmd. 

Lemma  7  Jfntasks  cannot  be  feasibly  scheduled  on  processors  using  the  IFF  condition, 
then  the  total  utilization  of  the  n  tasks  is  greater  than 

Theorem  8  Let  N  and  No  be  the  number  of  processors  required  by  RRM-FF  and 
the  minimum  number  of  processors  required  to  feasibly  schedule  a  given  set  qf  tasks, 
respectively.  Then  ^  2.0.  The  upper  bounds  of  RRM-FF  with  regard  to  oi 

are  given  in  Table  3  for  a  few  values  of  a. 

Proof:  Let  E  =  {niTz.- be  a  set  of  n  tasks,  with  their  utilizations 

{ui,U2, •••»ttn}>iespectively.  Hien  the  total  utilization  of  the  task  set  is  given  by 
^s*  Suppose  that  Np  and  Nq  processors  are  used  by  RRM-FF  to  schedule  the  task 
set  S,  where  Np  and  Nq  are  the  numbers  of  processors  allocated  in  processor  group  P 
and  processor  group  Q,  respectively.  Then  N  ^Np-\-  Nq.  Among  the  Np  processors, 
let  ni  be  the  number  of  processors  assigned  one  task  and  na  be  the  number  of  processors 
assigned  two  tasks.  Then  Np  —  ni+  ns- 

In  the  processor  group  P,  for  the  m  processors  to  each  of  which  one  task  is  assigned, 
^  ^  ^  ”2  processors  to  each  of  which  two  tasks  are 

assigned,  Ha)  >  ^  since  tij,!  >  1/3  and  tif,2  >  1/3. 

In  the  processor  group  Q,  among  all  Nq  processors,  each  of  them  must  be  assigned 
at  least  two  tasks  except  possibly  for  the  last  processor,  since  Ui  <  1/3.  According  R> 
Lemma  4,  among  all  processors,  on  each  of  which  at  least  two  tasks  are  assigned,  there 
are  at  most  one  processor  whose  utilization  is  less  than  or  equal  to  2(2y^  —  1),  tiien  we 
have 


'£iH>{NQ~  1)2(2*/’  - 1)  > 


Since  ES,  Ui  >  E2.K> + “i.2)  >  EJS 


n  Ua  tip  «  .  1*»  o 

=  ^H  +  ^(«i,l+tti,2)+5]^Ui>— r - 7-, 

i=l  i«l  i=l 

i.e.,  the  total  utilization  of  all  processors  is  equal  to  the  total  utilizations  of  all  tasks  in 
a  task  set. 

Since  Nq  >  Ui .  it  follows  from  above  that  2No  +  l-j-  In  2/2  >  N.  Therefore, 

^“jRAf-FF  ^  2. 
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For  Q  <  2*^*  -  1,  then  each  processor  in  the  first  processor  group  P  must  be  assigned 
two  tasks.  By  arguments  similar  to  the  above  one  and  the  one  in  the  proof  of  Theorem  . 
we  obtain  the  results  that  are  listed  in  Table  3.  ■ 


5.  Bate«Monotonic-Best*f1t  and  Its  Refinement 

When  RM-FF  schedules  a  task,  it  always  assigns  it  to  the  lowest  indexed  processor  on 
which  die  task  can  be  scheduled.  This  strategy  may  not  be  optimal  in  some  cases.  F(^ 
exannple,  the  lowest  indexed  processor  on  which  a  task  is  scheduled  may  be  the  one 
.  with  the  largest  available  utilization  among  all  those  bu^  (non>idle)  processors.  This 
processor  could  have  been  used  to  execute  a  future  task  with  large  enough  utilization  so 
>  diat  it  could  not  be  scheduled  on  any  busy  processors,  had  it  not  been  assigned  a  task 
with  a  small  utilization  earlier  on.  In  order  to  overcome  these  likely  disadvantages,  a 
new  algorithm  is  designed,  which  is  based  on  the  Best>Fit  bin-packing  algorithm. 

It  is  a  well-known  fact  that  die  Best-Fit  heurisdc  has  the  same  worst-case  performance 
bound  as  the  Hrst-Ht  (Cofifinan  et  al.,  1975),  Ybt  we  cannot  automatically  conclude 
from  the  bin-packing  results  that  RM-FF  and  RM-BF  will  have  the  same  worst-case 
perfonnance  bound,  because  of  the  difference  between  the  bin-packing  problem  (i.e.,  die 
classical  one-dimensional  bin-packing)  and  the  RMMS  problem.  The  major  difference 
is  diat  the  sizes  of  bins  in  bin-packing  are  unitary  and  the  utilizations  of  processors  are 
values  ranging  from  In  2  to  1  as  given  by  the  schedulability  condition. 

In  bin-packing,  when  an  item  is  allocated  by  the  Best-Ht,  the  lowest  indexed  bin  in 
which  the  item  can  be  fit  juid  whose  content  is  the  largest  among  all  the  nnn-ftmpty  bins 
in  which  the  item  can  be  fit,  is  chosen  to  contain  die  item.  Since  die  "sizes”  of  die  bins 
are  unitary,  finding  die  fitting  bin  whose  content  is  the  largest  among  all  the  non-empty 
fitting  bins  is  equivalent  to  finding  the  fitting  bin  whose  available  space  is  the  smallest 
among  all  the  non-empty  fitting  bins.  This  "equivalence”  property  of  Best-Ht  does  not 
hold  when  Best-Ht  is  used  to  schedule  tasks  on  jurocessors.  The  “unfilled”  utilization 
of  a  processor  is  not  only  determined  by  the  total  utilization  of  die  tasks  assigned  to  it, 
but  also  by  the  number  of  tasks.  Therefore,  it  is  possible  that  the  available  udlizadon 
of  a  irocessor  with  a  currendy  large  utilization  is  larger  than  that  of  a  processor  with  a 
currently  small  utilization.  For  example,  processcn*  Pi  is  currendy  assigned  two  tasks, 
each  with  a  udlizadon  of  (2^^®  —  1)  «  0.259.  Then  the  total  utilization  of  processor 
Pi  is  I/i  =  2(2^/*  - 1)  <  0.52,  and  the  available  utilization  of  Pi  is  (2'/®  -- 1).  For 
another  processor  Pa  to  which  one  task  with  a  utilization  of  U2  —  0.52  is  assigned,  its 
available  utilization  is  given  by  (1  -  0.52)/(l  +0.52)  >  0.31.  Iherefoie,  the  available 
utilization  of  processor  P3  is  larger  than  that  of  processor  Pi  even  though  Ui  <  U2.  The 
schedulability  condition  used  in  both  the  calculations  is  the  one  in  expression  (1). 

In  other  words,  there  are  at  least  two  notably  different  ways  in  which  the  Best-Fit 
heuristic  can  be  qjplied  to  allocating  tasks  to  processors:  one  is  to  find  the  "fitting** 
processor  with  the  largest  utilization,  and  the  other  is  to  find  the  "fitting”  processor  with 
the  smallest  available  utilization.  Presumably  these  two  vanations  might  have  different 
worst-case  performance  bounds.  In  the  following,  we  only  investigate  one  variation  of 
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the  Best-Fit  strategy,  where  the  "best  fit”  is  the  “fitting”  processor  with  the  smallest 
available  utilization. 

Algorithm  RM-BF:  Let  the  processors  be  indexed  as  Pi,  P2»  •  •  ••  with  each  initially  in 
the  idle  state,  i.e.,  with  zero  utilization.  The  tasks  {ri,r2,...,Tn},  which  are  ordered 
according  to  their  non-decreasing  periods,  will  be  scheduled  in  that  order.  To  schedule 
n,  find  the  least  j  such  that  task  Ti,  together  with  all  the  tasks  that  have  been  assigned  to 
processor  Pj  can  be  feasibly  scheduled  according  to  the  condition  2(1  -I-  1 

for  a  single  processor,  and  2(1  -f  - 1  be  as  small  as  possible,  and  assign  task 

n  to  Pj,  where  and  Uj  are  the  numter  of  tasks  already  assigned  to  processor  Pj  and 
the  total  utilization  of  die  kj  tasks,  respectively. 

\l\fith  its  “minimal  unfilled  udlization”  strategy  in  assigning  tasks  to  processors,  the  RM- 
BF  algorithm  does  not  outperform  RM-FF  in  the  worst  cases,  as  shown  by  Theorem  9. 
Before  we  prove  the  bounds  for  RM-BF,  the  following  definition  is  needed. 

Definition.  For  all  the  processors  required  to  schedule  a  given  set  of  tasks  by  RM-BF, 
they  are  divided  into  two  types  of  processors; 

Type  for  all  the  tasks  {ri,T2,  ...,Tn}  widi  utilizations  that  were 

assigned  to  a  processor  Px  in  the  completed  RM-BF  schedule,  there  exists  at  least  one 
task  Ti  with  i  >  2  that  was  assigned  to  Px,  not  because  it  could  not  be  assigned  on  any 
processor  Py  with  lower  index,  i.e.,  y  <x,  but  because  2(1  +]Ci*i  «x,i/(*— 

1  <  2(l+^"iiWj,,i/ny)”'"v  —  1,  where  riy  is  the  number  of  tasks  assigned  to  processor 
Py.  Processor  Px  is  called  a  Type  (I)  processor.  Such  a  task  t<  is,  for  convenience, 
referred  to  as  a  task  with  Type  ®  property. 

Type  (II):  They  consist  of  all  the  processors  that  do  not  belong  to  Type  (I). 

The  following  lemma  follows  immediately  from  Lemma  3. 

Lemma  B  If  n  tasks  cannot  be  feasibly  scheduled  on  n  —  1  processors  according  to 
RM-BF,  then  the  total  utilization  of  the  set  of  tasks  is  greater  than  n(2^/^  —  1). 

Lemma  9  In  the  completed  RM-BF  schedule,  if  the  mth  task  on  any  of  the  Type  (I) 
processors  has  "type  (I)  property,  where  m  >  2,  then  the  total  utilization  of  the  first 
(m  - 1)  tasks  on  that  processor  is  greater  than  (m  -  1)(2'/”*  —  1). 

Proof:  Let  {7>,i,7>;,2,  •  • . ,  71b,OT-i}  be  the  tasks  that  were  assigned  a  processor  Pk  of 
Type  (I),  and  Py,  wi^  y  <  k,  is  one  of  the  processors  on  which  Tm  could  have  been 
scheduled,  but  2(1  -1-  Ukjt/{m  -  l))-("»-i)  ~  1  <  2(H-  X:?=i 
where  ny  is  the  number  of  tasks  assigned  to  processor  Py,  and  wherevux,i  is  the  utilization 
of  task  Tx,i  on  jffocessor  P*. 

Since  >  2(1  +  YdZi  *“  ^  (”0*®  is  true  even  though  Tk,i 

is  assigned  to  processor  Pk  before  some  of  tasks  among  the  Uy  tasks  are  assigned  to 
procesror  Py),  for  1  <  *  <  m  -  1,  it  follows  that  Uk,i  >  2(1  +  ^ 

>  2(1  +  tik,i/im  -  —  1.  Summing  up  these  (m  - 1)  inequalities  yields 

m— I  in— 1 

j  >  2(7n  -  1)[H-  52  -  1))“('"- 


-  (m  -  1). 
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Solving  the  above  equation  yields 

m— 1 

Uk,j  >(m-  l)(2*/"‘  -  1). 


The  following  lemma  is  key  to  the  proof  of  Theorem  9. 


Lemma  10  In  the  completed  RM-BF  schedule,  among  the  processors  of  7V»^  m 
«hich  Ae  second  task  has  Type  (/)  pntperty,  there  are  at  J^J^aft^e^kZ 
which  has  a  total  utilization  less  them  2(2^/®  —  1).  f  m,  k  of 


Proof:  This  lemma  is  proven  by  contradiction.  Let  Pf,  P-, 
processors,  each  of  which  has  a  total  utilization  less  than  2(2^^^ 
i.e.,  ' 


Pk»  and  Pi  be  the  four 

-l)with«<y  <k</. 


E 

Xssl 


U 


<  2(21/3  - 1) 


2(21/3-1) 

a5»l 

X^l 


<2(21/3-1) 


r^l 


pA"L"a«,^Uveiy’^ 

Let’s  defliie  u,.,  and  n.-,,  to  be  the  utilizations  of  the  flist  task  Tj ,  and  second  task 
Ti,j  assign^  to  process^  P,.  uy,,  and  uj,.  to  be  the  utilizations  of  the  Aist  task  Z, 
‘■“•PKd  to  proper  P,.  ua,,  and  tta^,  u,.,  and  u, ,  ate  sindtay 
defined.  Ve  ftrfer  Msume  thu  n,  » the  number  of  tasks  which  have  b^  assiZTm 
piwessor  Pi.  when  the  second  task  on  processor  Pj  is  assigned.  Note  that  a  <i  ai!d 

There  are  three  cases  to  consider.  ' 

Case  1:  Tasks  ry.i  and  rjf,2  are  assigned  to  processor  P,-  after  task  r-  o  is  assiVnftH  tn 
processor  P.  Since  task  r,,  is  a  Type  (1)  task,  the  following  ineSta  h^ 


2(1  -1-  uy.i)“i  -  1  <  2[1  +  ^ 

®=i 


-1. 
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Note  that  riy  >  2,  i.e.,  other  tasks  may  have  been  assigned  to  processor  Pi  after  task 
r-  5  but  before  t^i  is  assigned  to  processor  Pj. 

we  have 

-2 


2(1  +  —  1  <  2(1  4-  Ui,i/2)  *  —  1, 


i.e.  1 >  (1  "b  ttt,i/2)?.  ^  ^ 

Case  2:  Tasks  Tj,i  and  rj,2  are  assigned  to  processor  Pj  after  task  r<,i  is  assigned  to 

orocessor  Pi  but  before  task  Ti.2  is  assigned  to  processor  Pi. 

This  case  is  impossible  with  RM-BF  scheduling.  Since  u*,*  <  2(2  1)  and 

u-  >  (2^^^  -  1)  according  to  Lemma  9,  Ui,2  <  2(2^/®  -  1)  -  (2^^*  - 1)  »  0.1056. 
Since  task  t^,2  is  assigned  to  processor  Pj  before  task  ri,2  is  assigned  to  processor  Pi, 
and  task  tj,2  is  a  Type  (I)  task,  2(1  +  Ui,i)~^  —  1  >  2(1  +  —  1,  i.e.. 

Since  task  Ti,2  is  also  a  Type  CD  task,  it  must  be  true  according  to  die  definition  that 

n. 


2(1  +  —  1  <  2(1  4-  ”•  1, 


x*=l 

where  n*  is  the  number  of  tasks  that  have  been  assigned  to  processor  Pj  after  task  r,-,2, 
but  before  task  Ti,2  is  assigned  to  processor  P*.  Note  that  it  is  conceivable  that  other  tasks 
may  have  been  assigned  to  processor  Pj  after  task  rj,2  hut  before  task  Ti,2  is  assigned 

to  processor  Pt.  .  ,  i  .  . 

Sin«2(l  +  Ui,,)-‘-l  <2(1  + ./«.)■”■  -1  < 2(1+ 

«t  1  >  «i,i-  This  is  a  contradiction  to  equation  (21). 

Case  3:  Task  Tj.i  is  assigned  to  processor  Pj  after  task  Ti,i  is  assigned  to  processor 
P,  and  task  Tj,2  is  assigned  to  processor  Pj  after  task  Ti,2  is  assigned  to  processor  P*. 
Since  task  Tj,2  is  a  Type  ©  task,  the  following  inequality  must  hold 


2(1  +  - 1  <  2(1  +  X)  - 1 


Note  that  riy  >  2,  i.e.,  other  tasks  may  have  been  assigned  to  processor  Pi  after  task 
Ti  2  but  before  t,-,2  is  assigned  to  processor  Pj.  .  ,  ,  , 

Since 2(l+EJil<«.x/’»»)' - -  <  2ll+(u(,,+l«,,)/2l-"-l  <  2(1+<k,/2)-=-1, 

we  have  2(1  +  —  1  <  2(1  +  Ui,i/2)  1.  i.e.,  1  +  Uj,i  >  (1  +  . 

Therefore  for  processors  Pi  and  Pj,  we  have 


1  +  Uj,i  >  (1  +  Ui,iJ2y 


(22) 


For  the  tasks  assigned  on  processors  Pj  and  Pfc,  and  Pk  and  J^,  it  can  be  similarly 
proven  that 
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1  +  «A'.l  >  (1+  Wi.l/2)2 

1  +  >  (1  +  W/,i/2)^ 


(23) 


(24) 


Sumiiung  up  equations  (22),  (23).  and  (24)  yields  u,,>rn2  2  a  ^ , 

Since  u,-,i  >  (2^2  _ 2\  „  ^  /2i/2 _  jv  *’* 

U,,1  >  3(2>/’  -  1)!>/4+(2»V»  - 1)  =  0.5429  >  2(2  */il  n  ®- 

to  die  assumption  that  «/,*  <  2(2^/^  _  j  j  results  in  a  contradiction 

Theorem  9  Let  N  and  iVk  Ap 

/*«  minimum  number  of  processors  reauired’^ttX^’^hf^^’^  required  by  RM-BF  and 

respecHvely  Then  2.2833  <  IhnAr  ^N/N  ^  o/  /ayfo. 

2(2V3  _  1).  -  ““^0-00  N/No  <  2  +  (3  -  23/2)/a  «  2.33.  M^hem  a  = 

Proof:  Similar  to  what  we  have  done  in  «A/'Hnn  o  z  u 

Ihe  same  vwighting  ftmcdon  lo  m^  ihe  ■«iii>4[-n  nf  algotiHun,  we  use 

Nob  (hat  ail  the  lelevaut  lemmas  in  section  3  Md  2  («.  IJ- 

the  RM-BF  schedule.  ^  processors  of  Type  (II)  in 

?  T  . . . , Too}  be  a  set  of  n  tasks  with  th^ir  *: 

respective  y.  and  a;  =  p?  ,  f(uA  Rv  t  J  ®  uhlizattons  «i,  «2, . . . 

S^pose  Aat  among  ^  =  2(2Vi  -  i*)^’ 

set  E  of  tasks.  M  of  them  belongs  om  schedule  a  given 

T>pe  (I)  must  be  assigned  at  leasuwo  tLks  there  exi^^n®*  processors  of 

number  m  with  m  >  2  such  that  the  mth  teJu  •  ^  ^  processor  at  least  an 

of  Type  CO  on  each  of  which  the  mth  task  is  a  ^  processors 

dtw.  2T2"  “4  “  X'  ^“'pX‘«rorc'rd.*  “  ■“* 

d  '  ■"  *'  "  am  at  nmat  tlnec 

Type  00  processors  in  the  RM-BF  schedule.  Since  /(“) 


n 

>  "-Wo(l-(2>/a_i)/<.].^_3_ 

we  have 

JV/JVb  S  (2a  + 1  -  2(2  >/a  _  «  2  33_ 

where  a  =  2(2*/^  —  1). 
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The  lower  bound  is  proven  by  repeating  the  same  argument  in  Theorem  6  for  RM-BR 
Therefore,  2.2833  <  limriro-»oo  Af/No- 

Note  that  even  though  RM-BF  has  the  same  worst-case  performance  bound  as  RM- 
FF  soecial  cases  exist  where  RM-BF  performs  better  than  RM-FF,  and  vice  versa.  For 
wUpIe.  for  a  set  of  four  tasks  with  their  utilizations  given  as  follows,  two  processors 
are  needU  by  RM-BF  while  three  processors  are  required  by  RM-FF  to  schedule  it 
*  2/5,  U2  »  3/7  -I-  e,  U3  *  (4  -  76)/(10  -h  Te).  and  U4  *  3/7  for  arbitrarily  small 

£  >  0» 

Let  o  be  the  maximum  allowable  utilization  of  a  task,  i.e.,  a  —  maXi{Ci/Ti}.  Hien 
we  can  prove,  similar  to  what  we  have  done  in  section  4  that  when  ot  is  small,  the  woml- 
case  performance  of  RM-BF  can  be  significantly  improved,  as  stated  in 
Based  on  similar  observation,  we  can  modify  RM-BF  to  develop  a  new  algorithm  called 
Refined-Rate-Monotonic-Best-Fit  (RRM-BF)  to  cope  vwth  situations  where  a  is  large. 

rrM-BF  works  as  follows:  it  divides  the  processors  into  two  groups  such  that  wi^n 
each  group  there  is  a  semi-infinite  number  of  processors.  It  also  divides  the  task  set  into 
two  groups  accacding  to  their  utilizations  such  that  tasks  within  a  group  aie  ^signed 
to  the  group  of  processors.  A  task  n  belongs  to  the  first  group  if  its  utilization 
is  larger  than  1/3,  i.e.,  m  >  1/3,  otherwise  it  belongs  to  the  second  group,  ‘^e  twks 
■fr  “n  . . .  Tn}  will  be  scheduled  in  tfiat  order.  To  schedule  n,  RRM-BF  first  idenhfies 
the  task  it  belongs  to,  and  then  find  the  least  i  such  that  task  Ti,  together 
all  the  tasks  that  have  been  assigned  to  jn-ocessor  Pj  (or  Qj),  can  be  feasibly  scheduled, 
and  assign  task  r<  to  Pj.  The  Best-Fit  heuristic  is  used  to  assign  tasks  in  both  groijps. 
The  schedulability  condition  used  to  schedule  tasks  with  utilizations  less  than  or  equd  to 
1/3  is  2(1  +  Uj/kjY^*  -  1,  where  kj  and  are  as  defined  above.  The  schedulability 
condition  used  to  schedule  tasks  with  utilizations  larger  than  1/3  is  the  necessary  and 
sufficient  condition. 

The  major  result  concerning  RRM-BF  is  stated  in  Theorem  11.  The  proof  of  both 
Theorem  10  and  Theorem  11  is  left  as  an  exercise  for  the  reader. 


Theorem  10  Let  N  and  No  be  the  number  of  processors  required  by  RM-BF  and 
the  minimum  number  of  processors  required  to  feasibfy  schedule  a 
respectively.  Further  let  a  =  maxi<<<n{«i}.  //«  <  - 1,  then  ^ 

_  /ore- 0,1, 2,.. .  Whenc—*oo,  (c-l-l)(2i/t*+‘'>-l)  — ♦  ln2.  Then 

BF  ^  1^5*  bounds  of  RM-BF  with  regard  to  a  are  gi\ 

for  a  few  values  of  ot. 


given  in  Table  2 


Theorem  ll  Let  N  and  No  be  the  number  of  processors  required  by  RRM-BF  and 
the  minimum  number  of  processors  required  to  feasibly  schedule  a  given  set  of  tasks, 
respectively.  Then  ^  2.  The  upper  bounds  of  RRM-BF  with  regard  to  a  are 

given  in  Table  3  for  a  few  values  of  a. 
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6.  Empirical  Studies  of  the  Nevir  Algorithms 

In  this  study,  the  perfonnance  bounds  of  the  new  algorithms  were  derived  under  worst- 
case  assumptions.  While  a  worst-case  analysis  assures  that  the  performance  bounds  are 
satisfied  for  some  large  task  set,  it  does  not  provide  insight  into  the  average-case  behavior 
of  the  algorithms,  lb  obtain  the  average-case  performance  of  the  new  algorithms,  one  can 
analyze  the  schemes  with  probabilistic  assumptions,  or  conduct  simuladon  experiments 
to  empirically  study  the  average-case  performance.  Since  a  probabilisdc  analysis  of  our 
algorithms  is  beyond  the  scope  of  this  study,  we  resort  to  simulation  to  gain  insight  into 
the  average-case  behavior  of  the  new  algorithms. 

We  present  simulation  experiments  for  large  task  sets  with  100  <  n  <  1000 
In  each  experiment,  we  vary  the  value  of  parameter  a— the  maximal  load  factor  of  any 
task  in  the  set,  i.e.,  or  =  inaXi{Ci/T|}.  The  task  periods  are  assumed  to  be  uniformly 
distributed  with  values  1  <  Ti  <  500.  The  run-times  of  the  tasks  are  also  taken  from 
a  uniform  distribution  with  range  1  <  Ci  <  ar<.  The  performance  metric  in  all  exper¬ 
iments  is  the  number  of  processors  required  to  execute  a  given  task  set.  Wfe  compare 
the  new  schemes  with  die  existing  scheme  NextFit-M  (NF-M)  in  the  literature.  All 
assignment  schemes  are  executed  on  identical  task  sets. 

Since  an  optimal  schedule  cannot  be  calculated  for  large  task  sets,  we  use  the  total 
utilization  <x  load  {U  =  of  the  task  set  as  the  lower  bound  for  the  number 

of  {vocessors  required. 

The  outcome  of  the  simulation  experiments  is  shown  in  Figure  2  and  Figure  3.  The 
maximum  utilization  of  a  task  is  set  to  a  =  0.2,  0.4,  0.6,  0.8  in  both  set  of  experiments. 
Each  data  point  depicts  the  average  value  of  20  independently  generated  taclf  sets  with 
identical  parameters.  Note  that  our  four  algorithms  consistently  nutparforms  NF-M.  In 
Figure  2,  the  perfonnance  of  RM-FF  and  RM-BF  is  almost  the  same.  We  therefore  only 
plot  the  performance  of  RM-FF  in  Hgure  3  for  comparison.  Also  the  performance  of 
RM-FF  and  RRM-FF  (or  RM-BF  and  RRM-BF)  cannot  be  distinguished  since  they  are 
identical  when  ot  <  1/3.  As  we  increase  the  value  of  a  from  1/3  to  1,  we  observe 
that  the  performance  of  RRM-FF  and  RRM-BF  improves  and  then  degrade  a  little  bit, 
compared  to  that  of  RM-FF.  All  results  show  that  the  number  of  processors  required  foe 
each  algorithm  increases  proportionally  to  the  total  utilization  of  the  task  set. 


7.  Condusions 

In  this  paper,  we  investigated  the  problem  of  scheduling  a  set  of  periodic  tasks  on  a 
multiprocessor  system  so  as  to  minimize  the  number  of  processors  used.  Four  on-line  al¬ 
gorithms  were  developed  using  a  newly  derived  schedulabili^  condition.  The  worst-case 
analysis  shows  that  both  algorithms  RRM-FF  and  RRM-BF  have  a  worst-case  perfor¬ 
mance  bound  of  2.  The  perfonnance  of  the  algorithms  can  be  significantly  improved 
when  the  maximum  allowable  utilization  of  a  task  is  small.  This  worst-case  bound  is 
the  currently  the  best  for  on-line  allocation  algorithms  for  solving  the  same  problem.  It 
is  also  equal  to  the  currently  known  best  bound  for  off-line  algorithms.  Simulation  is 
conducted  to  assess  the  average-case  behavior  of  the  algorithms.  Experimental  results 
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olpho  «  0.2 


Figure  2.  Average-case  Performance  of  RM-FF(BF)  and  NF-M. 
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indicate  that  the  four  algorithms  consistently  outperform  the  existing  on-line  algorithm 
NF-M. 

There  are  a  number  of  places  where  further  improvement  is  possible.  The  first  interest¬ 
ing  question  is  what  the  exact  bounds  of  the  heuristics  are  if  the  necessary  and  sufficient 
condition— the  IFF  condition  is  used  instead  in  scheduling  tasks.  The  second  queshon 
is  whether  there  exist  some  off-line  algorithms  whose  worst-case  performance  is  better 
than  the  cunentfy  known  bound  of  2.  Finally,  it  is  interesting  to  find  out  whether  a 
variation  of  the  Best-Rt  heuristic  other  than  the  one  we  investigated  in  this  paper  has  a 
better  worst-case  performance. 

Finally  we  vrant  to  remark  dwt  fliere  is  usually  a  time  l^e  between  the  discovery 
of  a  new  theory  and  its  practical  application.  The  Rate-Monotonic  Scheduling  was  first 
discovered  in  1972-1973  by  liu  and  Layland,  and  Serlin.  It  took  about  15  years  when  the 
Rate-monotonic  algorithm  was  actually  supported  by  a  real-time  operating  system.  Now 
the  Rate-monotonic  algorithm  has  been  used  widely  in  a  number  of  applications.  The  ^t 
result  on  Rate-Monotonic  Multiprocessor  Scheduling  (RMMS)  was  derived  around  1977- 
1978  by  Dhall  and  Liu.  Interests  in  real-time  task  scheduling  on  multiprocessor  systeiM 
have  been  increasing  rapidly,  due  to  the  inevitable  employment  of  multiprocessors  in 
many  real-time  systems.  The  results  obtained  in  this  paper  are  timely  results  for  the 
research  community  and  for  practitioners  at  large. 
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Appendix 

In  this  appendix,  we  show  that  some  errors  exist  in  the  proof  for  the  upper  bound  of 
RMFF  by  Dhall  and  Liu  in  (Dhall  and  Liu,  1978).  Their  RMFF  is  ^ost  the  same  as 
our  RM-FF  except  drat  in  their  RMFF,  the  IP  condition  is  used  wife  the  tarics  being 
sorted  in  the  order  of  increasing  period.  They  obtained  the  following  results: 

|  I:  If  n  tasks  cannot  be  feasibly  scheduled  on  n  -  1  ixocessors  acrording  to 
RMFF,  then  the  utilization  factor  of  the  set  of  tasks  is  greater  than  n/(l  +  2^'®). 

n:  If  are  assigned  to  the  processors  according  to  RMFF,  among  all 
processors  to  each  of  which  two  tasks  are  assigned,  there  is  at  most  one  processor  for 
which  tile  utilization  factor  of  the  set  of  the  two  tasks  is  less  than  1/2. 

Theorem  I:  Let  N  be  the  number  of  processors  required  to  feasibly  schedule  a  set  of 
tasks  by  RMFF.  and  AT©  the  minimum  number  of  processors  required  to  fe^ibly 
fee  same  set  of  tasks.  Then  as  AT©  approaches  infinity,  2  <  N/W©  <  4x2  ^®/(l+2  '  )(S 
0  23), 

Unfortunately.  Umma  I  is  incorrect,  as  shown  by  the  following  counter  example. 
Lemma  II  gives  a  weak  result  for  RMFF.  These  two  errors  led  fee  authors  to  arrive  at 


238 


Y.  OH  AND  S.H.  SON 


the  wrong  upper  bound.  In  the  following,  we  first  show  the  incorrectness  of  Lemma  I, 
and  then  give  a  strong  version  of  Lemma  II. 

Example:  consider  the  case  where  m  =  2  and  the  two  tasks  are  given  as  follows* 

Ti  =  (2»/*  -  1, 1), 

T2  =  (2  —  2^/^  +  e,2^/^),  where  c  is  a  small  number  and  e  >  0. 

According  to  RMFF,  ti  is  first  assigned  to  a  processor.  Since  tti  =  2^/*  -  1  and 
2(1  +  ui)  ^  —  1  =r  2*/^  —  1  <  2^^*  —  1  •+•  c/2^/^  =  U2,  T2  cannot  be  scheduled  together 
with  task  n  on  one  processor,  according  to  the  IP  condition.  Since  ti  and  r2  cannot  be 
scheduled  on  one  processor, ui  +ti2  must  be  greater  than  2/(1 +2^3)  s  0.88,  according 
to  Lemma  L  But  ui  +  U2  =  2(2^/*  - 1)  +  =  0.8284  +  e/2i/3  which  is  less  than 

0.88  for  small  £. 

A  stronger  (tight)  version  of  their  Lemma  n  can  be  given  in  the  following  lemma  The 
proof  is  similar  to  that  of  Lemma  4. 

Lemma  II  (Revised):  If  tasks  are  assigned  to  the  processors  according  to  RMFF, 
among  all  processors  to  each  of  which  two  tasks  are  assigned,  there  is  at  most  one 
processor  for  which  the  utilization  factor  of  die  set  of  the  two  tasks  is  less  than  2(2^/^— 1). 

Note  that  ^ntuna  I  is  true  if  their  RMFF  used  instead  the  necessary  and  sufficient 
condition  given  by  Joseph  and  Pandya  in  their  1986  paper  (Joseph  and  Pandya,  1986)  or 
by  Lehoczky  et  al  in  their  1989  paper  (Lehoczky  et  al.,  1989)  for  m  >  2,  and  our  new 
result  as  stated  in  Lemma  7.  It  may  be  the  case  that  Dhall  and  Liu  indeed  considered 
the  problem  of  scheduling  a  set  of  n  tasks  on  n  processors  (with  one  task  on  each 
processor),  and  obtained  the  result  in  Lemma  1.  However,  for  their  upper  bound  to  hold, 
the  necessary  and  sufficient  condition  must  be  used  in  their  RMFF  scheme  instead.  Iii 
either  case,  the  upper  bound  of  2.23  does  not  fit. 
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Abstract 

As  in  other  application  areas,  there  is  an  increasing  need 
for  managing  a  large  amount  of  data  in  the  real-time  area. 
This  need  gave  birth  to  a  system  called  a  real-time  database 
system  (RTDBS)  that  provides  database  operations  with 
timing  constraints.  One  typical  timing  constraint  in  an 
RTDBS  is  temporal  consistency  that  states  that  a  trans¬ 
action  must  read  temporally  valid  data  objects.  This  re¬ 
quires  the  data  objects  to  be  updated  repeatedly.  This  pa¬ 
per  proposes  three  novel  schemes  that  aim  to  minimize  the 
number  of  updates  of  data  objects  needed  for  guaranteeing 
the  temporal  consistency  requirements  of  transactions  with 
hard-deadlines.  The  three  guarantee  schemes  differ  from 
each  other  in  the  amount  of  updates  and  the  implemen¬ 
tation  complexity.  This  paper  also  gives  a  framework  for 
integrating  transactions  with  soft-deadlines  into  the  three 
guarantee  schemes. 


1  Introduction 

Recently,  computer  systems  are  increasingly  used  for 
monitoring  and  controlling  time  critical  systems  such  as 
industrial  machine  control  systems  ajid  flight  control  sys¬ 
tems  [1,  2,  3].  Such  computer  systems  are  called  real-time 
systems  and  they  generally  have  two  types  of  task:  hard- 
deadline  and  soft-deadline  tasks.  For  hard-deadline  tasks, 
it  is  required  that  they  be  completed  by  their  deadlines. 
On  the  other  hand,  for  soft-deadline  tasks,  the  goal  is  to 
meet  the  deadlines  of  as  many  of  them  as  possible.  Prob¬ 
lems  related  to  both  types  of  task  have  been  studied  in¬ 
tensively  in  the  real-time  area  [4,  5,  6,  7]. 

As  in  other  application  areas,  there  is  an  increasing 
need  for  managing  a  large  amount  of  data  in  the  real-time 
area.  This  need  gave  birth  to  a  system  called  a  real-time 
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database  system  (RTDBS)  that  provides  database  oper¬ 
ations  with  timing  constraints.  An  RTDBS  has  features 
that  distinguish  it  from  a  traditional  database  system. 
First,  it  manages  real-time  data  objects  which  reflect  the 
rapidly  changing  real-world  (e.g.,  chamber  temperature, 
aircraft  location  and  speed)  in  addition  to  traditional,  rel¬ 
atively  static  data  objects.  Such  real-time  data  objects  be¬ 
come  invaJid/obsolete  as  the  external  real-world  changes 
and  thus  they  should  be  updated  repeatedly  to  remain 
valid.  Second,  transactions  in  an  RTDBS  have  timing  con¬ 
straints.  One  type  of  such  timing  constraint  is  a  deadline. 
The  deadline  of  a  transaction  may  be  hard-deadline  or  soft- 
deadline  depending  on  its  functional  requirement.  Another 
timing  constraint  is  temporal  consistency.  There  are  two 
types  of  temporal  consistency:  absolute  and  relative  tem¬ 
poral  consistency.  The  absolute  temporal  consistency  re¬ 
quires  that  a  transaction  read  temporally  valid  (i.e.,  recent 
enough)  data  objects  and  be  committed  before  any  of  them 
becomes  invalid.  On  the  other  hand,  the  relative  temporal 
consistency  requires  that  update  times  of  data  objects  read 
by  a  transaction  be  close  enough  (a  more  formal  deflnition 
is  given  in  Section  2). 

Adelberg  et  al.  address  the  problems  arising  from  up¬ 
dates  of  real-time  data  objects  that  are  needed  so  that 
the  data  objects  are  temporally  valid  when  they  are  read 
by  transactions  [8,  9].  They  present  a  number  of  schemes 
that  aim  to  efficiently  balance  update  processing  and  soft- 
deadline  transaction  processing.  The  schemes  make  best 
efforts  to  maxiiiiize  the  number  of  transactions  that  are 
completed  by  their  deadlines  and  read  only  temporally 
valid  data  objects.  However,  the  problem  of  ensuring  that 
transactions  are  completed  before  any  of  data  read  by  them 
becomes  invalid  is  not  addressed.  To  attack  the  latter 
problem,  Xiong  et  al,  introduce  the  concept  of  a  data- 
deadline  after  which  some  real-time  data  objects  read  by 
a  transaction  become  invalid  [10,  11].  This  data-deadline 
concept  places  a  more  stringent  deadline  onto  the  transac¬ 
tion. 

Both  of  the  above  two  studies  handle  only  soft-deadline 
transactions.  Kim  and  Son  propose  a  scheme  that  handles 


both  haxd-deadline  and  soft-deadline  transactions  [12,  13]. 
The  scheme  guarantees  that  all  the  hard-deadline  transac¬ 
tions  meet  their  deadlines  without  violating  their  temporal 
consistency  requirements.  In  the  scheme,  the  update  pe¬ 
riod  of  a  real-time  data  object  is  set  to  be  less  than  a 
half  of  the  valid  interval  of  the  object  to  keep  it  always- 
fresh.  This  approach  results  in  a  large  number  of  updates 
whose  updated  values  are  not  actually  used  by  any  trans¬ 
action.  Such  needless  updates  consume  a  large  amount  of 
processing  time  and  thus  reduce  normal  processing  time 
for  hard-deadline  and  soft-deadline  transactions. 

In  this  paper,  we  propose  three  schemes  with  vary¬ 
ing  complexities  that  guarantee  the  deadlines  and  tempo¬ 
ral  consistency  requirements  of  hard-deadline  transactions 
while  minimizing  update  loads.  In  addition,  we  give  for 
each  proposed  scheme  a  schedulability  test  and  a  method 
for  computing  spare  capacity  that  can  be  used  to  process 
soft-deadline  transactions. 

This  paper  is  organized  as  follows:  The  next  section 
details  the  three  guarantee  schemes.  Section  3  explains 
how  to  integrate  the  processing  of  soft-deadline  transac¬ 
tions  into  the  three  guarantee  schemes.  In  Section  4,  we 
give  the  results  of  our  experiments  to  evaluate  the  perfor¬ 
mance  of  the  guarantee  schemes.  Finally,  we  conclude  this 
paper  in  Section  5. 


2  Guaranteeing  Hard-deadline  Trans¬ 
actions 

In  this  section,  we  describe  three  new  schemes  that  aim 
to  reduce  update  loads  while  guaranteeing  both  the  dead¬ 
lines  and  the  temporal  consistency  requirements  of  hard- 
deadline  transactions.  In  describing  the  schemes,  we  as¬ 
sume  the  following. 

•  Each  real-time  data  object  x  has  an  absolute  validity 
interval^  denoted  by  aut{x),  after  which  its  value  be¬ 
comes  invalid.  Thus,  a  real-time  data  object  must  be 
updated  before  its  absolute  validity  interval  expires 
to  remain  always  valid.  The  time  needed  to  update  x 
is  assumed  to  be  c(x). 

•  There  are  n  periodic  hard-deadline  transactions  de¬ 
noted  by  ri ,  •  •  • ,  Tn  where  ri  has  the  highest  priority 
and  r„  the  lowest  priority.  Each  hard-deadline  trans¬ 
action  n  has  the  following  attributes  that  are  given 
a  priori:  (1)  period  p,,  (2)  data  read  set  RS^  :  set 
of  data  objects  read  by  n,  (3)  execution  time  a  :  a 
worst  case  execution  time  estimate  obtained  ignoring 
the  time  for  updating  RS^y  and  (4)  deadline  d;. 

•  There  are  soft-deadline  transactions  that  arrive  ape- 
riodically.  Their  arrival  times  cannot  be  determined 
a  prion. 

•  Every  transaction  should  satisfy  both  of  the  following 
two  types  of  temporal  consistency  for  timing  correct¬ 
ness. 


1.  Absolute  temporal  consistency:  A  transac¬ 
tion  should  read  only  valid  real-time  data  objects 
and  complete  its  execution  before  the  absolute 
validity  interval  of  any  of  them  expires, 

2.  Relative  temporal  consistency:  The  differ¬ 
ence  between  the  commit  time  of  transaction  r 
and  the  timestamp  (i,e,  the  latest  update  time) 
of  any  data  object  in  RSt  should  be  less  than 
rvi(r),  which  is  called  the  relative  validity  in¬ 
terval  [13]  of  r.  More  formally,  the  condition 
can  6e  stated  as  follows, 

Vx  e  RSr  t  tcommit  (r)  —  t5tamp{^)  ^  rui(7') 

where  tcommit  (r)  and  t5tamp(x)  denote  the  com¬ 
mit  time  of  T  and  the  timestamp  of  x,  respec¬ 
tively. 

2,1  Guarantee  based  on  On-Demand  Up¬ 
date  (OD  Guarantee) 

One  possible  approach  to  minimizing  the  amount  of 
updates  is  to  update  real-time  data  objects  only  when 
they  are  actually  accessed  by  hard-deadline  transactions. 
This  scheme,  which  we  call  the  on-demand  (OD)  guarantee 
scheme,  guarantees  that  hard-deadline  transactions  always 
read  temporally  valid  data.  However,  there  stiU  remains 
a  need  for  a  transaction  to  be  committed  before  the  ab¬ 
solute  validity  interval  of  any  of  its  data  objects  expires. 
For  this  purpose,  we  adjust  the  deadline  of  a  hard-deadline 
transaction  n  as  follows. 

di  =  min  (er,j(x)  +  avt(x)) 

In  the  equation,  HP  is  the  hyperperiod  of  hard-deadline 
transactions  and  er,y(x)  is  the  earliest  possible  time  when 
X  can  be  accessed  by  r,j^.  Note  that  if  n  is  committed 
before  d;,  its  absolute  temporal  consistency  is  guaranteed 
for  aJl  the  instances  of  r,  in  the  hyperperiod. 

Similarly,  the  relative  temporal  consistency  of  r,*  can  be 
enforced  by  the  following  new  deadline  d,. 

i^rij{x)  -f-  rwi(r,)) 

J<^.xeRSri 

The  above  two  requirements  suggest  that  the  deadline 
of  transaction  Ti  be  given  as  follows  to  satisfy  both  the  ab¬ 
solute  and  relative  temporal  consistency  in  addition  to  the 
original  deadline  d,-,  which  is  given  as  part  of  application 
requirement. 

d-  =  mm{d.,d,,d,} 

With  this  setting,  we  perform  a  test  to  determine 
whether  a  given  set  of  hard-deadline  transactions  is  schedu- 
lable  based  on  the  response  time  approach  by  Joseph 

^  (®)  f®**  ^he  J-th  inst2ince  of  t,-  can  be  statically  calculated 
by  scheduling  the  hard-deadllne  transactions  in  the  hyperperiod 
assuming  their  best  case  execution  times. 
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Figure  1:  Advantage  of  the  OD  guarantee  scheme  over 
the  always-fresh  guarantee  scheme 

and  Pandya  [14].  In  the  OD  guarantee  scheme,  since 
every  instance  of  n  includes  the  update  times  of  data 
objects  in  RSra  the  task's  execution  time  is  given  by 
"bXIieitSr  gives  the  following  recursive  equa¬ 

tion  for  the  worst  case  response  time  of  r,. 

R,  =  ci+  c(*)+^r^Kc,+  Y 

x^RSri  J<i  xQRSrj 

This  worst  case  response  time  is  compared  against  to 
determine  the  schedulability  of  r,-. 

Figure  1  shows  the  benefits  of  using  the  proposed  OD 
guarantee  scheme  over  the  guarantee  schemes  based  on 
always-fresh  [10.  12,  13,  15].  In  the  e.xample,  we  assume 
that  there  is  a  real-time  data  object  x  whose  absolute  valid¬ 
ity  interval  is  6  and  it  is  read  by  two  hard-deadline  transac¬ 
tions  Ti  and  t2  whose  periods  are  15  and  22.5,  respectively. 
In  the  a/u'ays-/res/i  guarantee  scheme,  every  real-time  data 
object  is  updated  periodically  with  a  period  smaller  than 
a  half  of  the  object’s  data  validity  interval  to  maintain  the 
data  object  always-fresh.  Thus,  in  our  example,  the  up¬ 
dates  of  r  are  made  every  3  time  units  (cf.  Figure  1(a)). 
On  the  other  hand,  in  the  OD  guarantee  scheme,  the  up¬ 
dates  are  made  only  when  x  is  accessed  by  some  hard- 
deadline  transactions  (cf.  Figure  1(b)). 

In  our  example,  the  absolute  validity  intervals  of  real¬ 
time  data  objects  are  small  compared  to  the  periods  of 
hard-deadline  transactions.  This  leads  to  a  large  number  of 
needless  updates  in  the  always-fresh  scheme.  In  the  figure, 
these  needless  updates  are  denoted  by  black  rectangles. 
In  the  other  case  where  the  absolute  validity  intervals  of 
real-time  data  objects  are  large  compared  to  the  periods 
of  hard-deadline  transactions,  the  performance  of  the  OD 
guarantee  scheme  may  be  worse  than  that  of  the  always- 
fresh  scheme.  However,  since  the  OD  guarantee  scheme 
can  be  made  to  update  a  real-time  data  object  only  when 
it  is  invalid,  the  unused  update  times  that  result  when  the 
data  object  is  up-to-date  (i.e.,  gain  time  [6])  can  be  used 
to  process  soft-deadline  transactions. 


2.2  Guarantee  based  on  Periodic  Update 
(PU  Guarantee) 

In  this  subsection,  we  describe  another  guarantee 
scheme,  called  the  periodic  update  (PU)  guarantee  scheme, 
which  is  based  on  periodic  update  of  real-time  data  ob¬ 
jects  similar  to  the  always-fresh  scheme.  It  differs  from 
the  always-ftesh  scheme  in  that  the  update  periods  are  set 
to  the  maximum  values  that  do  not  violate  the  temporal 
consistency  requirements  of  hard-deadline  transactions. 

Let  p{x)  be  the  update  period  of  x.  Then,  the  intervals 
where  x  is  valid  are  given  as  follows. 

((t  -  l)p(x),  (t  -  l)p(x)  +  ot)t(j:))  t  =  1, 2, 3,  •  •  • 

To  guarantee  the  absolute  temporal  consistency  require¬ 
ments  of  hard-deadline  transactions  that  read  x,  each 
transaction  should  start  and  end  within  one  of  the  inter¬ 
vals.  More  formally,  this  condition  can  be  stated  as  follows. 

Vi,  j,  Vx  6  RSn,  ((j  -  l)p.-,(i  -  l)p.-  +  di) 

C  ((t  -  l)p(x).  (t  -  l)p(x)  +  ot;i(x)) 

In  addition,  to  guarantee  the  relative  temporal  consis¬ 
tency  requirements,  the  difference  between  the  timestamp 
of  X  and  the  latest  possible  commit  time  of  a  transaction 
r,  that  reads  x  should  be  less  than  the  relative  validity 
interval  of  r,-.  More  formzJly, 

Vx  €  RSn,  3t,  {j  -  l)pi  -h  di  -  (f  -  l)p(x)  <  rvi(n) 

By  setting  the  update  period  of  each  real-time  data  ob¬ 
ject  to  the  maximum  v«due  that  satisfies  the  above  two 
conditions,  the  total  update  load  can  be  reduced  compared 
to  the  always-fresh  scheme. 

Figure  2  compares  the  proposed  PU  guarantee  scheme 
with  the  always-fresh  guarantee  scheme  assuming  the  same 
settings  as  in  Figure  1.  In  the  example,  the  update  period 
of  X  in  the  PU  guarantee  scheme  is  given  as  7.5  that  sat¬ 
isfies  both  of  the  above  two  conditions.  From  our  discus¬ 
sion,  it  is  clear  that  the  PU  guarantee  scheme  performs  at 
least  as  good  as  the  always-fresh  guarantee  scheme.  In  the 
worst  case,  the  performance  of  the  PU  guarantee  scheme 
converges  to  that  of  the  aJways-fresh  scheme. 

2.3  Guarantee  based  on  Aperiodic  Up¬ 
date  (AU  Guarantee) 

Even  in  the  PU  guarantee  scheme,  some  needless  up¬ 
dates  are  inevitable  due  to  its  periodic  nature.  To  rectify 
this  problem,  this  subsection  proposes  a  guarantee  scheme 
called  the  aperiodic  update  (AU)  guarantee  scheme  where 
updates  of  real-time  data  objects  are  made  aperiodically. 
The  key  problem  in  the  AU  guarantee  scheme  is  how  to 
determine  the  exact  positions  in  the  hyperperiod  where  up¬ 
dates  are  necessary  to  guarantee  the  temporal  consistency 
requirements  of  hard-deadline  transactions. 

The  update  points  of  real-time  data  object  x  that  are 
needed  to  guarantee  the  absolute  temporal  consistency  can 
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Figure  2:  Example  of  the  PU  guarantee  scheme 

be  located  iteratively  as  follows:  The  first  update  is  made 
at  time  0  and  the  next  update  is  made  just  before  the  ar¬ 
rival  of  a  transaction  whose  arrival  time  is  earliest  among 
the  hard-deadline  transactions  with  commit  times  that  are 
beyond  the  validity  interval  of  the  first  update.  Other 
update  points  are  located  similarly.  In  addition,  updates 
are  needed  to  guarantee  the  relative  temporal  consistencv. 
The  points  of  these  updates  can  be  determined  similarly 
to  the  case  of  absolute  temporal  consistency.  In  the  ac¬ 
tual  implementation,  update  points  for  both  absolute  and 
relative  temporal  consistency  are  determined  in  a  single 
pass  to  eliminate  redundant  updates  that  might  occur  if 
the  two  temporal  consistency  requirements  are  addressed 
separately. 

In  the  Al  guarantee  scheme,  the  priority  of  an  aperiodic 
request  for  updating  x  is  initially  set  to  the  lowest  possible 
priority-  However,  when  a  hard-deadline  transaction  that 
reads  t  arrives,  the  update  request  inherits  the  priority  of 
that  transaction.  With  this  priority  inheritance,  the  worst 
case  response  time  of  r;  can  be  given  as  follows. 

Ri  =  Ci  +  2  k{x,  Ri)c(x) 

J<i  xQRSrjJ<i 

where  /:( j.  Ri )  is  the  number  of  update  points  of  x  in  in¬ 
terval  [O.i?,]. 

Figure  3  compares  the  AU  guarantee  scheme  with  the 
PU  guarantee  scheme  assuming  the  same  settings  as  pre- 
Niously.  From  the  example,  we  can  note  that  the  AU  guar¬ 
antee  scheme  eliminates  all  the  needless  updates  that  pre- 
wously  existed  in  the  PU  guarantee  scheme.  This  is  made 
possible  by  allowing  aperiodic  update  of  real-time  data  ob- 
jects. 


3  Scheduling  of  Soft-deadline  Transac¬ 
tions 

Soft-deadline  transactions  axe  processed  using  spare 
processing  capacity  left  after  guaranteeing  hard-deadline 


Figure  3:  Example  of  the  AU  guarantee  scheme 

transactions.  Many  schemes  that  have  been  proposed  to 
make  use  of  this  spare  processing  capacity  [5,  6,  16,  17] 
can  be  applied  to  our  three  guarantee  schemes  with  minor 
changes.  In  this  paper,  we  concentrate  on  the  dynamic 
slack  stealing  approach  by  Davis  et  al.  [6].  This  approach 
gives  a  method  for  computing  the  slack  time  5r,  (<),  which 
is  the  spare  time  that  is  available  at  time  i  for  processing 
aperiodic  tasks  without  violating  the  deadline  of  a  hard- 
deadline  task  n.  This  method  can  be  used  to  compute 
the  maximum  time  that  can  be  provided  for  soft-deadline 
task  processing  at  time  t  without  violating  the  deadline  of 
any  hard-deadline  task  (in  particular  this  maximum  time 
is  given  as  mini  Sri{i}  and  for  more  details  of  the  dynamic 
slack  stealing  algorithm,  refer  to  [6]). 

This  dynamic  slack  stealing  can  be  directly  applied  to 
the  OD  and  PU  guarantee  schemes  since  all  the  tasks  in 
these  schemes  including  those  for  updating  real-time  data 
objects  are  periodic.  For  the  AU  guarantee  scheme,  the 
slack  value  Sr^  (t)  of  n  should  be  reduced  by  the  amount  of 
processing  time  for  updates  that  have  been  pre-scheduled 
to  occur  before  the  next  deadline  of  ri. 

When  soft-deadline  transactions  are  scheduled  using 
slacks,  their  processing  and  additional  updates  for  their 
temporal  consistency  should  be  balanced  so  that  as  many 
of  them  as  possible  can  be  serviced  before  their  deadlines. 
For  this  purpose,  the  guarantee  schemes  proposed  in  this 
paper  can  make  use  of  the  balancing  schemes  explained  in 
[8,  9]. 


4  Experimental  Results 

In  this  section,  we  present  the  results  of  our  simula¬ 
tion  study  to  compare  the  performance  of  the  guarantee 
schemes  proposed  in  this  paper.  Only  the  always-fresh, 
OD,  and  AU  guarantee  schemes  are  evaluated,  since  we 
are  still  working  on  the  PU  guarantee  scheme.  In  ad¬ 
dition,  we  explore  only  the  effects  of  absolute  temporal 
consistency  requirements  since  we  expect  that  the  relative 
temporal  consistency  requirements  have  similar  effects  on 


Figure  4:  Breakdown  utilization  according  to  Pread 
{La.i  =  0.5) 


Figure  5:  Breakdown  utilization  according  to  Pread 
{Lavi  =  2.0) 


Figure  6:  Breakdown  utilization  according  to  Pread 
{^avi  —  5.0) 


the  performance  to  those  of  absolute  temporal  consistency 
requirements. 

The  performance  of  the  guarantee  schemes  is  evaluated 
in  terms  of  breakdown  utilization  U*  [18]  over  which  a 
given  transaction  set  is  not  schedulable.  In  our  experiment, 
the  breakdown  utilization  is  obtained  as  follows:  First,  we 
generate  a  random  transaction  set  that  consists  of  10  hard- 
deadline  transactions.  Each  transaction  is  given  a  period 
from  the  uniform  distribution  on  the  interval  from  100  to 
2000  and  its  deadline  is  set  equal  to  the  period.  The  ex¬ 
ecution  time  Ci  is  given  by  a  =  0-lp»(o»7  Xlyli  ®i)  where 

*  •  * ,  aio  are  random  values  drawn  from  the  uniform  dis¬ 
tribution  on  the  interval  [0,1].  This  choice  of  the  execu¬ 
tion  time  is  made  so  that  the  utilization  of  the  transaction 
set  {U  =  ^Tci/p,-)  is  0.1.  Second,  the  generated  trans¬ 
action  set  is  related  to  a  random  data  set  that  consists 
of  5  real-time  data  objects  by  two  parameters,  Pread  and 
Zavi.  The  first  parameter  Pread  is  the  probability  that  a 
transaction  r,*  read  a  real-time  data.  Thus,  this  parameter 
determines  the  data  read  set  RSn^  The  second  parame¬ 
ter  Lavi  determines  the  absolute  validity  intervals  of  the 
real-time  data  objects  relative  to  the  periods  of  the  trans¬ 
actions  in  the  generated  transaction  set.  Specifically,  the 
absolute  validity  interval  of  a  real-time  data  object  is  given 
by  multiplying  the  period  of  a  randomly  chosen  transac¬ 
tion  and  Lavi*  Next,  the  times  required  for  updating  the  5 
real-time  data  objects  are  randomly  drawn  from  the  uni¬ 
form  distribution  on  the  interval  from  1  to  20.  Finally,  we 
multiply  each  a  by  a  small  factor  6  and  increase  8  until 
the  scaled  up  transaction  set  is  decided  to  be  unschedula- 
ble  by  a  given  guarantee  scheme.  The  utilization  at  that 
point  (U*  =  5!^^c,7p,  )  is  the  breakdown  utilization  of  the 
guarantee  scheme  for  the  given  transaction  set  and  data 
set.  To  observe  the  general  effects  of  Pread  and  Lavi  on 
the  breakdown  utilization,  we  generate  500  random  sam¬ 
ples  with  a  given  pair  of  Pread  and  Lavi  and  average  the 


breakdown  utilizations  for  those  samples. 

Figure  4  compares  the  performance  of  the  always- fresh, 
OD,  and  AU  guarantee  schemes  when  Prcad  varies  from 
0.0  to  1.0  with  Lavi  =  0.5.  As  expected,  the  AU  guaran¬ 
tee  scheme  gives  the  best  performance  throughout  since  it 
does  not  suffer  from  needless  updates.  When  Prcad  is  low 
(i.e.,  when  RSn  is  small),  the  OD  guarantee  scheme  out¬ 
performs  the  always-fresh  scheme  since  the  former  needs 
only  a  small  number  of  update  requests  while  the  latter 
requires  a  constant  number  of  updates,  which  is  indepen¬ 
dent  of  the  number  of  real-time  data  objects  read  by  each 
transaction.  As  Prcad  increases,  the  deadlines  of  trans¬ 
actions  induced  by  the  absolute  temporal  consistency  are 
tightened  because  more  real-time  data  objects  are  read  by 
transactions.  Thus,  U*  for  all  the  three  guarantee  schemes 
decreases.  Moreover,  in  the  OD  guarantee  scheme,  since 
each  instance  of  transactions  entails  update  requests  for 
all  the  real-time  data  objects  read  by  it,  as  more  real-time 
data  objects  are  read  by  a  transaction,  a  larger  number 
of  updates  are  required.  Thus,  U*  of  the  OD  guarantee 
scheme  decreases  faster  than  the  always-fresh  scheme  and 
there  exists  a  cross-over  point  over  after  which  the  always- 
fresh  scheme  outperforms  the  OD  guarantee  scheme. 

The  same  trends  can  be  observed  in  Figures  5  and  6 
where  the  Lavi  value  is  set  to  2.0  and  5.0,  respectively. 
From  these  figures,  we  can  notice  that  as  Lavi  increases, 
the  I  '  values  for  all  three  guarantee  schemes  become 
larger.  This  is  because  as  Lavi  increases,  the  deadlines 
of  transactions  get  relaxed.  Note  that  an  increase  in  Lavi 
lengthens  the  absolute  validity  intervals  of  real-time  data 
objects.  In  addition,  as  the  absolute  validity  intervals  of 
real-time  data  objects  are  lengthened,  a  smaller  number  of 
updates  are  required  by  the  always-fresh  guarantee  scheme 
because  the  update  intervals  of  real-time  objects  are  also 
lengthened.  This  is  also  true  for  the  AU  guarantee  scheme. 
However,  in  the  OD  guarantee  scheme,  the  required  num¬ 
ber  of  updates  does  not  change  as  the  absolute  validity 
intervals  are  lengthened  since  it  does  not  depend  on  the  ab¬ 
solute  validity  intervals  but  depends  on  the  number  of  in¬ 
stances  of  transactions.  Thus,  the  U*  value  of  the  always- 
fresh  scheme  increases  faster  than  that  of  the  OD  guar¬ 
antee  scheme  as  Lavi  increases.  This  explains  why  the 
cross-over  point  between  the  two  curves  shifts  to  left  in 
Figures  4,  5,  and  6. 

In  summary,  the  AU  guarantee  scheme  always  performs 
best  in  terms  of  the  breakdown  utilization.  The  always- 
fresh  guarantee  scheme  gives  a  relatively  high  breakdown 
utilization  when  the  absolute  validity  intervals  are  large 
and  each  real-time  data  object  is  read  by  many  transac¬ 
tions.  In  the  opposite  situation  where  the  absolute  validity 
intervals  are  small  and  each  real-time  data  object  is  read  by 
few  transactions,  the  OD  guarantee  scheme  outperforms 
the  always-fresh  scheme. 


5  Conclusion 

In  this  paper,  we  have  proposed  three  schemes  that 
aim  to  minimize  the  number  of  updates  of  real-time  data 
objects  that  are  needed  to  guarantee  the  temporal  con¬ 
sistency  of  hard-deadline  transactions.  Among  them,  the 
AU  guarantee  scheme  gives  the  best  performance  in  terms 
of  schedulabiiity  and  spare  capacity.  However,  the  AU 
guarantee  scheme  entails  aperiodic  processing  of  updates 
that  complicates  the  implementation  and  requires  a  large 
amount  of  storage  to  maintain  all  the  update  points  of 
real-time  data  objects.  On  the  other  hand,  in  the  OD  and 
P U  guarantee  schemes  all  the  processing  including  that  of 
updates  is  periodic,  thus  simplifying  the  implementation, 
but  they  generate  a  substantial  number  of  needless  up¬ 
dates.  Thus,  there  is  a  trade-off  relationship  among  the 
three  proposed  schemes.  We  are  currently  developing  an 
evaluation  platform  that  includes  a  task  generator,  an  op¬ 
timization  problem  solver,  a  schedulabiiity  tester,  and  a 
simulator  to  study  this  trade-off. 
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ABSTRACT 


Database  systems  for  real-time  applications  must  satisfy  timing  constraints 
associated  with  transactions,  in  addition  to  maintaining  data  consistency.  In 
addition  to  real-time  requirements,  security  is  usually  required  in  many 
applications.  Multilevel  security  requirements  introduce  a  new  dimension  to 
transaction  processing  in  real-time  database  systems.  In  this  paper,  we  argue  that 
because  of  the  complexities  involved,  tradeoffs  need  to  be  made  between  security 
and  timeliness.  We  first  describe  a  secure  two-phase  locking  protocol.  The  protocol 
is  then  modified  to  support  an  adaptive  method  of  trading  off  security  for 
timeliness,  depending  on  the  current  state  of  the  system.  The  performance  of  the 
Adaptive  2PL  protocol  is  evaluated  for  a  spectrum  of  security-factor  values  ranging 
from  fully  secure  (1.0)  right  upto  fully  real-time  (0.0). 
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1.  Introduction 


Database  security  is  concerned  wth  the  ability  of  a  database  management  system  to  enforce  a  security 
policy  governing  the  disclosure,  modification  or  destruction  of  information.  Most  secure  database  systems 
use  an  access  control  mechanism  based  on  the  Bell-LaPadula  model  [Bell  76].  This  model  is  stated  in 
terms  of  subjects  and  objects.  An  object  is  understood  to  be  a  data  file,  record  or  a  field  within  a  record.  A 
subject  is  an  active  process  that  requests  access  to  objects.  Every  object  is  assigned  a  classification  and 
every  subject  a  clearance.  Classifications  and  clearances  are  collectively  referred  to  as  security  classes  (or 
levels)  and  they  are  partially  ordered.  The  Bell-LaPadula  model  imposes  the  following  restrictions  on  all 
data  accesses: 

a)  Simple  Security  Property:  A  subject  is  allowed  read  access  to  an  object  only  if  the  former’s  clearance  is 
identical  to  or  higher  (in  the  partial  order)  than  the  latter’s  classification. 

b)  The  *-Property:  A  subject  is  allowed  write  access  to  an  object  only  if  the  former’s  clearance  is  identical 
to  or  lower  than  the  latter’s  classification. 

The  above  two  restrictions  are  intended  to  ensure  that  there  is  no  flow  of  information  from  objects  at  a 
higher  access  class  to  subjects  at  a  lower  access  class.  Since  the  above  restrictions  are  mandatory  and 
enforced  automatically,  the  system  checks  security  classes  of  all  reads  and  writes.  Database  systems  that 
support  the  Bell-LaPadula  properties  are  called  multilevel  secure  database  systems  (MLS/DBMS). 

The  Bell-LaPadula  model  prevents  direct  flow  of  information  from  a  higher  access  class  to  a  lower 
access  class,  but  the  conditions  are  not  sufficient  to  ensure  that  security  is  not  violated  indirectly  through 
what  are  known  as  covert  channels  [Lamp  73].  A  covert  channel  allows  indirect  transfer  of  information 
from  a  subject  at  a  higher  access  class  to  a  subject  at  a  lower  access  class.  An  important  class  of  covert 
channels  that  are  usually  associated  with  concurrency  control  mechanisms  are  timing  channels.  A  timing 
channel  arises  when  a  resource  or  object  in  the  database  is  shared  between  subjects  with  different  access 
classes.  The  two  subjects  can  cooperate  with  each  other  to  transfer  information. 

A  real  time  database  management  system  (RTDBMS)  is  a  transaction  processing  system  where  transac¬ 
tions  have  explicit  timing  constraints.  Typically  a  timing  constraint  is  expressed  in  the  form  of  a  deadline, 
a  certain  time  in  the  future  by  which  a  transaction  needs  to  be  completed.  In  a  real-time  system,  transac¬ 
tions  must  be  scheduled  and  processed  in  such  a  way  that  they  can  be  completed  before  their  correspond¬ 
ing  deadline  expires.  Conventional  data  models  and  databases  are  not  adequate  for  time-critical 
applications.  They  are  designed  to  provide  good  average  performance,  while  possibly  yielding  unaccept¬ 
able  worst-case  response  times.  As  advances  in  multilevel  security  take  place,  MLS/DBMSs  are  also 
required  to  support  real-time  requirements.  As  more  and  more  of  such  systems  are  in  use,  one  cannot  avoid 
the  need  for  integrating  real-time  data  processing  techniques  into  MLS/DBMSs.  In  [Son  93],  the  security 
impact  on  real-time  database  systems  is  studied,  but  to  the  best  of  our  knowledge,  no  work  has  been 
reported  on  developing  DBMSs  which  are  multilevel  secure  and  which  support  real-time  applications. 

Concurrency  control  is  used  in  databases  to  manage  the  concurrent  execution  of  operations  by  different 
subjects  on  the  same  data  object  such  that  consistency  is  maintained.  In  multilevel  secure  databases,  there 
is  the  additional  problem  of  maintaining  consistency  without  introducing  covert  channels.  For  a  more 
detailed  description  of  and  a  possible  solution  to  the  problem  of  concurrency  control  in  secure  databases, 
the  reader  is  referred  to  [Dav  93].  In  this  paper,  we  discuss  the  additional  issues  that  arise  when  transac¬ 
tions  in  a  secure  database  have  timing  constraints  associated  with  them.  Section  2  is  an  overview  of  related 
work  in  secure  concurrency  control.  In  Section  3,  the  problems  associated  with  time-constrained  secure 
concurrency  control  are  studied  and  possible  solutions  are  evaluated.  In  Section  4,  a  specification  of  the 


secure  two  phase  locking  protocol  [Dav  93]  is  provided.  The  inherent  limitations  of  a  fully  secure  concur¬ 
rency  control  protocol  for  a  secure  database  and  a  method  by  which  security  can  be  partially  compromised 
for  improved  deadline  cognizance  is  presented  in  Section  5.  In  Section  6,  a  simulation  system  for  a  secure 
database  system  is  described  and  the  performance  of  a  modified  Secure  2PL  for  various  degrees  of  mainte¬ 
nance  of  the  security  properties  is  evaluated.  Section  7  concludes  the  paper. 

2.  Background 

2.1  Correctness  Criteria  for  Secure  Schedulers 

Covert  channel  analysis  and  removal  is  the  single  most  important  issue  in  multilevel  secure  concurrency 
control.  The  notion  of  non-interference  has  been  proposed  [Gogu  82]  as  a  simple  and  intuitively  satisfying 
definition  of  what  it  means  for  a  system  to  be  secure.  The  property  of  non-interference  states  that  the  out¬ 
put  as  seen  by  a  subject  must  be  unaffected  by  the  inputs  of  another  subject  at  a  higher  access  class.  This 
means  that  a  subject  at  a  lower  access  class  should  not  be  able  to  distinguish  between  the  outputs  from  the 
system  in  response  to  an  input  sequence  including  actions  from  a  higher  level  subject  and  an  input 
sequence  in  which  all  inputs  at  a  higher  access  class  have  been  removed  [Keef  90a]. 

An  extensive  analysis  of  the  possible  covert  channels  in  a  secure  concurrency  control  mechanism  and 
the  necessary  and  sufficient  conditions  for  a  secure,  interference-free  scheduler  are  given  in  [Keef  90a]. 
Three  of  these  properties  are  of  relevance  to  the  secure  two  phase  locking  protocol  discussed  in  this  paper. 
For  the  following  definitions,  given  a  schedule  s  and  an  access  level  /,  purge(s,l)  is  the  schedule  with  all 
actions  at  a  level  >  I  removed  from  s. 

1)  Value  Security:  A  scheduler  satisfies  this  property  if  values  read  by  a  subject  are  not  affected  by  actions 
with  higher  subject  classification  levels.  Stated  formally,  for  an  input  schedule  p,  the  output  chi  dule  s  is 
said  to  be  value  secure  if  purge(s,l)  is  view  equivalent  to  the  output  schedule  produced  for  purge(p,l). 

2)  Delay  Security:  This  property  ensures  that  the  delay  experienced  by  an  action  is  not  affected  by  the 
actions  of  a  subject  at  a  higher  classification  level.  An  action  a/  is  said  to  be  delayed  with  respect  to 
another  action  02  if  and  only  if: 

•  The  action  a  /  appears  before  02  in  the  input  schedule. 

•  The  action  aj  follows  02  in  the  output  schedule. 

•  The  action  02  is  the  last  action  in  the  input  schedule  for  which  the  first  two  conditions  are  satisfied. 

For  an  input  schedule  p  and  an  output  schedule  s,  a  scheduler  is  delay  secure  if  for  all  levels  /  in  p,  each 
of  the  actions  aj  in  purge(p,l)  is  delayed  with  respect  to  02  in  the  output  schedule  produced  for  purge(p,l)  if 
and  only  if  it  is  delayed  with  respect  to  in  purge(s.l). 

3)  Recovery  Security:  A  set  of  transactions  is  in  a  deadlock  state  when  every  transaction  in  the  set  is  wait¬ 
ing  for  an  event  that  can  only  be  caused  by  another  transaction  in  the  set  (such  as  release  of  a  lock).  Dead¬ 
lock  is  a  problem  unique  to  locking  protocols  and  is  not  an  issue  in  timestamp  schedulers  and  optimistic 
concurrency  control.  Even  these  sch^ulers,  however,  can  reach  a  state  from  which  they  cannot  continue 
without  aborting  one  or  more  transactions.  For  simplicity,  these  two  conditions  are  lumped  together  and 
called  as  deadlock  (Keef  90a]. 

When  a  deadlock  is  detected,  some  of  the  actions  in  the  schedule  must  be  aborted,  allowing  the  others  to 
proceed.  If  resolving  the  deadlock  can  allow  a  high-level  transaction  to  modify  the  values  read  by  a  low 
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level  transaction  or  to  affect  the  delay  a  Ionv  level  transaction  experiences,  a  covert  channel  can  arise. 
When  a  deadlock  occurs,  other  channels  are  available  for  signaling  in  addition  to  those  protected  by  value 
security  and  delay  security.  The  following  condition  takes  care  of  these  channels: 

A  scheduler  is  recovery  secure  for  all  schedules  p  if,  on  the  arrival  of  an  action  Ax  for  scheduling: 

1)  If  a  deadlock  occurs,  resulting  in  a  set  of  actions  D  being  rolled  back,  then  for  all  subject  classification 
levels  I  in  p,  which  dominate  one  of  those  in  D,  a  deadlock  also  occurs  in  response  to  the  schedule 
purge(l,p)  on  the  arrival  of  the  action with  the  actions  purge(l,D)  being  rolled  back. 

2)  If  no  deadlock  occurs  on  the  arrival  of  Ag,  then  for  all  subject  classification  levels  I  in  p,  it  does  not 
occur  on  the  arrival  of  Ag  in  the  input  schedule  purge(l,p). 

Recovery  security  ensures  that  the  occurrence  of  a  deadlock  appears  the  same  to  a  low-level  subject, 
independent  of  whether  higher  level  actions  are  in  the  schedule  or  not.  The  actions  taken  to  recover  from 
deadlock  are  also  not  affected  by  the  presence  of  higher  level  transactions. 

2.2  Approaches  to  Secure  Concurrency  Control 

In  this  section,  we  discuss  some  of  the  existing  concurrency  control  algorithms  and  see  why  they  yield 
unacceptable  performance  for  secure  databases. 

2.2.1.  Locking  and  Timestamp  Ordering 

Locking  will  fail  in  a  secure  database  because  the  security  properties  prevent  actions  in  a  transaction  Tj 
at  a  higher  access  class  from  delaying  actions  in  a  transaction  T2  at  a  lower  access  class  (e.g.  when  T2 
requests  a  conflicting  lock  on  a  data  item  on  which  Tj  holds  a  lock).  Timestamp  ordering  fails  for  similar 
reasons,  with  timestamps  taking  the  role  of  locks,  since  a  transaction  at  a  higher  access  class  cannot  cause 
the  aborting  of  another  transaction  at  a  lower  access  class.  There  are  approaches  for  adapting  locking  and 
timestamping  techniques  for  MLS/DBMSs.  For  example,  in  [Rubi  92],  two  copies  of  a  data  item  are  main¬ 
tained  at  level  L,  one  for  subjects  at  level  L  and  one  for  subjects  which  dominate  level  L.  Subsequently, 
locking  and  timestamp  based  concurrency  control  techniques  are  proposed. 

2.2.2.  Optimistic  Concurrency  Control 

Optimistic  concurrency  control  for  a  secure  database  can  be  made  to  work  by  ensuring  that  whenever  a 
conflict  is  detected  between  a  transaction  7),  at  a  higher  access  class  in  its  validation  phase  and  a  transac¬ 
tion  7/  at  a  lower  access  class,  the  transaction  at  the  higher  access  class  is  aborted,  while  the  transaction  at 
the  lower  access  class  is  not  affected.  A  niajor  problem  with  using  optimistic  concurrency  control  is  the 
possible  starvation  of  higher-level  transactions.  For  example,  consider  a  long-running  transaction  7),  that 
must  read  several  lower-level  data  items  before  the  validation  stage.  In  this  case,  there  is  a  high  probability 
of  conflict  and  as  a  result,  T^,  may  have  to  be  rolled  back  and  restarted  an  indefinite  number  of  times.  This 
issue  will  be  analyzed  in  greater  detail  in  Section  6. 

2.2.3.  Multiversion  Timestamp  Ordering 

A  secure  version  of  the  MVTO  scheduler  is  presented  in  [Keef  90b].  The  difference  between  Basic 
MVTO  and  Secure  MVTO  is  that  Secure  MVTO  will  sometimes  assign  a  new  transaction  a  timestamp  that 
is  earlier  than  the  current  timestamp.  This  effectively  moves  the  transaction  into  the  past  with  respect  to 
active  transactions.  To  be  more  precise,  when  a  transaction  begins,  it  is  assigned  a  timestamp  that  precedes 
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the  timestamps  of  all  transactions  active  at  strictly  dominated  access  classes  and  that  follows  the  times¬ 
tamps  of  all  transactions  at  its  own  access  class.  This  approach  to  timestamp  assignment  is  what  makes  it 
impossible  for  a  transaction  to  invalidate  a  read  from  a  higher  access  class.This  method  has  the  drawback 
that  transactions  at  a  higher  access  class  are  forced  to  read  arbitrarily  old  values  from  the  database  because 
of  the  timestamp  assignment.  This  problem  can  be  especially  serious  if  most  of  the  lower  level  transactions 
are  long  running  transactions. 

2.2.4  Replicated  Database  Architectures 

In  [Koga  90],  Kogan  and  Jajodia  discuss  a  concurrency  control  mechanism  in  secure  databases  using  a 
replicated  architecture  which  guarantees  serializable  execution  of  concurrent  transactions.  This  protocol, 
however,  has  the  same  problem  as  that  associated  with  the  Secure  MVTO  algorithm,  where  transactions  at 
a  higher  access  class  might  be  forced  to  read  arbitrarily  old  values. 

3.  Security  and  Real-Time  Requirements 

There  are  two  approaches  which  can  be  explored  to  design  real-time  concurrency  control  algorithms  for 
databases: 

•  Improvements  to  existing  concurrency  control  algorithms  for  secure  databases  to  make  them  time-cogni¬ 
zant. 

•  Correctness  criteria  weaker  than  serializability  which  would  result  in  increased  concurrency.  A  discus¬ 
sion  of  this  approach,  however,  is  beyond  the  scope  of  this  paper. 

There  have  been  a  number  of  papers  in  the  real-time  databases  literature  that  have  explored  these 
approaches  with  respect  to  conventional  databases  [Abbo  92],[Sha  87],[Hari  90],  [Son  92].  The  problem 
arises  when  these  approaches  are  applied  to  secure  databases,  because  covert  channels  can  be  introduced 
by  priority  based  scheduling.  All  existing  real-time  systems  schedule  transactions  based  on  some  priority 
scheme.  The  priority  usually  reflects  how  close  the  transaction  is  to  missing  its  deadline.  Priority-based 
scheduling  of  real-time  transactions,  however,  interacts  with  the  property  of  non-interference  which  has  to 
be  satisfied  by  secure  schedulers  [Keef  90a].  Take  the  sequence  of  transactions  input  to  a  scheduler  as 
shown: 

Ti  (SECRET)  :  R(X) 

T2  (UNCLASSIFIED)  :  W(X) 

T3  (UNCLASSIFIED)  :  W(X) 

T4  (UNCLASSIFIED)  :  R(X) 

Assume  that  Tj,  Tj  and  Tj  have  priorities  5,  7  and  10  respectively  and  the  priority  assignment 
scheme  is  such  that  if  priority(T2)  >  priority(T i),  then  T2  has  greater  criticalness  and  has  to  be  scheduled 
ahead  ofTp  In  the  above  example,  T2  and  7j  are  initially  blocked  by  Tj  when  they  arrive.  When  Tj  com¬ 
pletes  execution,  T^  is  scheduled  ahead  of  T2,  since  it  has  a  greater  priority  than  and  the  transaction  exe¬ 
cution  order  would  be  Tj  T2  T4.  However,  if  the  transaction  Tj  is  removed,  the  execution  order  would  be 
Ti  Tj  T4  because  7*2  would  have  been  scheduled  as  soon  as  it  had  arrived.  The  presence  of  the  SECRET 
transaction  Tj  thus  changes  the  value  read  by  the  UNCLASSIFIED  transaction  T4,  which  is  a  violation  of 
value  security.  For  the  same  reason  delay  security  is  also  violated,  because  the  presence  of  Tj  delays  T2 
with  respect  to  Tj. 

It  is  easy  to  see  that  the  problems  with  any  concurrency  control  mechanism  are  present  because  a  higher 


-4- 


level  transaction  cannot  interfere  with  the  execution  of  a  lower  level  transaction.  This  makes  the  mecha¬ 
nism  unfair,  because  higher  level  transactions  are  starved  for  service. 

A  transaction  at  a  higher  access  class: 

•  Cannot  cause  the  aborting  of  a  transaction  at  a  lower  access  class.  If  it  is  allowed  to  do  so,  it  is  possible 
that  it  can  control  the  number  of  times  a  lower  level  transaction  is  aborted,  thereby  opening  a  covert 
channel. 

•  Cannot  conflict  with  a  transaction  at  a  lower  access  class.  If  such  a  conflict  does  occur,  the  higher  level 
transaction  has  to  be  blocked  or  aborted,  not  the  low  level  transaction. 

•  Cannot  be  granted  greater  priority  of  execution  over  a  transaction  at  a  lower  access  class. 

A  real-time  secure  concurrency  control  algorithm  must  possess  two  characteristics  -  speed  and  minimal 
deadline  miss  percentage.  The  secure  two  phase  locking  protocol  [Dav  93]  was  shown  to  yield  best  aver¬ 
age  case  performance  among  all  the  secure  concurrency  control  approaches  whose  performance  was  eval¬ 
uated  in  [Son  94].  We  therefore  use  it  as  a  basis  for  our  solution  to  the  problem  of  real-time  secure 
concurrency  control.  From  our  discussion  earlier  in  this  section,  it  is  clear  that  priority-based  transaction 
scheduling  is  not  feasible  for  a  fully  secure  database  system.  Therefore,  for  minimizing  deadline  miss  per¬ 
centage,  we  take  the  approach  that  partial  security  violations  under  certain  conditions  are  permissible,  if  it 
results  in  substantial  gain  in  time  cognizance.  In  the  next  section,  the  Secure  2PL  protocol  is  described,  and 
in  the  subsequent  section,  the  design  of  a  tradeoff  factor  between  the  security  properties  and  the  real-time 
requirements  is  explained. 

4.  Secure  Two-Phase  Locking 

Basic  two-phase  locking  does  not  work  for  secure  databases  because  a  transaction  at  a  lower  access 
class  (say  T})  cannot  be  blocked  because  of  a  conflicting  lock  held  by  a  transaction  at  a  higher  access  class 
(Tf,).  If  T/  were  somehow  allowed  to  continue  with  its  execution  in  spite  of  the  conflict,  then  non-interfer¬ 
ence  would  be  satisfied.  The  basic  principle  behind  the  secure  two-phase  locking  protocol  is  to  try  to  sim¬ 
ulate  execution  of  Basic  2PL  without  blocking  of  lower  access  class  transactions  by  higher  access  class 
transactions. 

4.1.  An  Example 

Consider  the  two  transactions  in  example  1: 

Ti  (SECRET)  :  r[x]  cj 

Tj  (UNCLASSMED)  :  w[xj  C2 

EXAMPLE  1 

Basic  two  phase  locking  would  fail  because  W2[x]  would  be  blocked  waiting  for  Tj  to  commit  and 
release  rlj[x].  In  our  modification  to  the  two-phase  locking  protocol,  T2  is  allowed  to  set  a  virtual  lock 
VWI2IX],  write  onto  a  version  of  x  local  to  T2  and  continue  with  the  execution  of  its  next  operation,  i.e.  €2- 
When  Tj  commits  and  releases  the  lock  on  x,  T2's  virtual  write  lock  is  upgraded  to  a  real  lock  and  W2[x]  is 
performed.  Until  vt'2/jcy  is  performed,  no  conflicting  action  is  allowed  to  set  a  lock  on  x.  The  sequence  of 
operations  performed  is  therefore,  rljlx]  rj[x]  vwl2[x]  C2  •••  c/  ruj[xJ  wl2[xj  W2M  wu2[x]. 

This  modification  alone  is  not  enough,  as  illustrated  in  Example  2: 
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T,  (SECRET)  :  r[x]  r[y]  cj 

T2(UNCLASSIHED)  :  w[x]  w[y]  C2 

EXAMPLE  2 

The  sequence  of  operations  that  would  be  performed  is  rl][x]  rj[x]  vwl2[xj  vw2[x]  WI2M  W2[y]  02- 
After  these  operations,  deadlock  would  occur  because  rily]  waits  for  W2[yl  to  release  its  virtual  lock  and 
vw2[x]  waits  for  rj[x]  to  release  its  lock.  This  deadlock  would  not  have  occurred  in  basic  two-phase  lock¬ 
ing.  Note  that  our  aim  of  trying  to  simulate  execution  of  basic  two  phase  locking  is  not  being  achieved.  On 
closer  inspection,  it  is  obvious  that  this  problem  arises  because  W2ly]  is  allowed  to  proceed  with  its  execu¬ 
tion  even  though  W2M  could  only  write  onto  a  local  version  of  x  because  of  the  read  lock  rl][xj  set  by  Tj. 
To  avoid  this  problem,  for  each  transaction  T,-,  two  lists  are  maintained  -  before(Ti)  which  is  the  list  of 
active  transactions  that  precede  7}  in  the  serialization  order  and  after(Ti)  which  is  the  list  of  active  transac¬ 
tions  that  follow  Ti  in  the  serialization  order.  This  idea  is  adapted  from  [Son  92],  where  before_cnt  and 
after_cnt  are  used  to  dynamically  adjust  the  serialization  order  of  transactions.  The  following  additions  are 
made  to  the  basic  two-phase  locking  protocol: 

1)  When  an  action  pi[x]  sets  a  virtual  lock  on  x  because  of  a  real  lock  qlj[x]  held  by  Tj,  then  T,-  and  all  trans¬ 
actions  in  afteiiTJ  are  added  to  after(Tj),  7}  and  all  transactions  in  before(Tj)  are  added  to  before(Ti). 

2)  When  an  action  w^lx]  arrives  and  finds  that  a  previous  action  Wi[y]  (for  some  data  item  y)  has  already 
set  a  virtual  write  lock  vwl^ly],  then  a  dependent  lock  dywl^fx}  is  set  with  respect  to  vwljy}. 

3)  When  an  action  p/x/  arrives  and  finds  that  a  conflicting  virtual  or  dependent  lock  vqlj[x]  or  dvqljfx]  has 
been  set  by  a  transaction  Tj  which  is  in  after(Ti),  then  Pi[x]  is  allowed  to  set  a  lock  on  x  and  perform  Pi[x] 
in  spite  of  the  conflicting  lock. 

4)  A  dependent  virtual  lock  dvpjx],  dependent  on  some  action  qjfy]  is  upgraded  to  a  virtual  lock  when 
vqljlx]  is  upgraded  to  a  real  lock. 

The  maintenance  of  a  serialization  order  and  the  presence  of  dependent  locks  are  necessary  to  prevent 
uncontrolled  acquisition  of  virtual  locks  by  transactions  at  lower  access  classes. 

For  example  2,  the  sequence  of  operations  that  would  now  be  performed  is  rljfxj  rjlxJ  vwl2[xj  dvwl2ly] 
C2  rljly]  rj[y]  cj  nijM  ruj[y]  wl2[x]  W2[x]  wu2[x]  wl2[y]  W2[yJ  wu2[y]. 

The  conditions  given  above  are  necessary  to  ensure  that  Delay  Security  is  satisfied,  but  Value  Security 
could  still  be  violated  as  shown  in  Example  3. 


T,  (TOP  SECRET) 

T2  (SECRET) 

T3  (CLASSIFIED) 

T4  (UNCLASSIFIED) 


ri[y]  rilxj  •••  Cj 

r2[z]  C2 

W3M  W3U]  Cj 

W4[y]  W4IZ]  C4 


EXAMPLE  3 


When  T4  requests  a  write  lock  on  Tj  already  holds  a  real  lock  on  ‘y\  i.e.,  T,  is  set  before  T4  in  the 
serialization  order.  When  T,  requests  a  read  lock  on  ‘x’,  T3  already  holds  a  write  lock  on  ‘x’,  i.e.,  T3  is  set 
before  Tj  in  the  serialization  order.  When  T3  requests  a  write  lock  on  'z\  T4  already  holds  a  dependent 
lock  on  'z’.  However.  T3  is  before  Tj  in  the  serialization  order  and  T]  is,  in  turn,  before  T4  in  the  serializa¬ 
tion  order,  i.e.,  T3  is  before  T4  in  the  serialization  order  and  so,  W3[z]  is  allowed  to  supersede  W4[z]  in  the 
lock  queue  for  ‘z’.  Now,  when  r2lz]  is  submitted,  it  will  read  the  value  of  'z'  written  by  T4.  However,  if  T, 
had  not  been  present,  then  T3  would  not  have  been  before  T4  in  the  serialization  order.  This  means  that 
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W3[z]  would  not  have  superseded  W4[z]  in  the  lock  queue  for  ‘z’,  i.e.,  r2[z]  would  have  read  the  value  of  ‘z’ 
written  by  T3.  Since  the  value  read  by  a  SECRET  transaction  is  affected  by  the  presence  of  a  transaction  at 
the  TOP  SECRET  level.  Value  Security  is  being  violated. 

In  general,  an  action  in  transaction  Tj  can  supersede  an  action  in  transaction  T2  if  Tj  is  before  T2  in  the 
serialization  order.  Now,  Value  Security  could  be  violated  if  Tj  is  before  T2  in  the  serialization  order 
because  of  the  presence  of  a  transaction  T3  at  a  higher  access  class,  i.e.,  if  T3  is  between  T j  and  T2  in  the 
serialization  order.  To  overcome  this  problem,  the  action  in  Tj  is  not  allowed  to  supersede  the  action  in  T2 
if  such  a  case  arises. 

4.2.  The  Three  Lock  Types 

The  semantics  of  the  three  different  kinds  of  locks  are  explained  below: 

1)  Real  Lock  (of  the  form  plfxj):  A  real  lock  is  set  for  an  action  pfx]  if  no  other  conflicting  action  has  a 
real  lock  or  a  virtual  lock  on  x.  The  semantics  of  this  lock  are  identical  to  that  of  the  lock  in  basic  two- 
phase  locking. 

2)  Virtual  Lock  (of  the  form  vplfxj):  A  virtual  lock  vplfxj  is  set  for  an  action  pfxj  if  a  transaction  at  a 
higher  access  class  holds  a  conflicting  lock  on  x  (pfx]  has  to  be  a  write  to  satisfy  the  Bell-LaPadula  prop¬ 
erties).  The  virtual  lock  is  non-blocking.  Once  a  virtual  lock  vplfxj  is  set,  pfxj  is  added  to  queue[xj  and 
the  next  action  in  7}  is  ready  for  scheduling.  When  pfxj  gets  to  the  front  of  the  lock  queue,  its  virtual  lock 
is  upgraded  to  a  real  lock  and  pfx]  is  submitted  to  the  scheduler.  A  virtual  lock  holding  action  vplfxj  can 
be  superseded  in  the  lock  queue  by  a  conflicting  action  qjx]  if  Tj  is  in  before(Ti). 

3)  Dependent  Virtual  Lock  (of  the  form  dvpli[x]):  A  dependent  virtual  lock  is  set  for  an  action  pfx]  (where 
p  is  a  write)  if  a  previous  write  wfyj  in  the  same  transaction  holds  a  virtual  lock.  An  action  pfx]  which 
holds  a  dependent  virtual  lock  with  respect  to  another  action  wfyj  is  not  allowed  to  set  a  real  lock  or  a  vir¬ 
tual  lock  unless  wfyfs  virtual  lock  is  upgraded  to  a  real  lock.  The  dependent  lock  is  non-blocking  and  can 
be  superseded  by  a  conflicting  action  qj[x]  if  Tj  is  before  7}  in  the  serialization  order. 

4.3.  The  Secure  Two-Phase  Locking  Protocol 

The  Secure  2PL  scheduler  manages  its  locks  according  to  the  following  rules: 

When  an  action  pfx]  is  submitted,  one  of  three  possible  cases  can  arise: 


Case  1  (p  =  read)  A,3{wLock(Tj,  x)  v  VwLock(Tj,x)  \r  DVwLock(TpX) ) 

Read  value  of  x  written  by  wfxj; 

Case  2  ({p  =  write)  a  3rLock  ( x) ) 

Upgrade  rLock(Ti,x)  to  wLock(Ti,x); 

Case  3 

3j{(qLock(Tj,x)  v  VqLock(Tj,x)  v DVqLock{T.,x)  \f  Wait{T^,x))  a  (j^i) 
A  (  (p  =  write)  V  (^  =  write) )  ) 
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pos  :=  length(queue[x]); 
while  ( pos >0) 

Tj  f-  transaction  at  queue  [x]  — >  pos; 
if  (operation( queue  [x]  pos  )  conflicts  with  p) 

if  {T,€  before (Tj)) 

Vr3  ((73  €  before  (Tj)  )^(T^€  after  (T;)  ) 

A  (SL(T^)  >SL(T.))  A  iSL(T^)  >SL(Tj))  ) 

abort  Tj;  /*  value  security  violation  */ 
if(lock( queue  [x]  ->  pos  )  is  a  real  lock)  /*  deadlock  V 
call  victim  selection  routine; 
if  (victim  =  7}J 
exit; 

else 

continue; 

if(Tii  before  {Tj)  ) 

if{  (p  =  write)  a  (3z,  VwLock  (T,-,  z) ) ) 

Insert(queue,DVwLock(Ti,x),pos);  /*  insert  after  pos  */ 
dependenftwfz])  :=  wfx]; 
else  if(SL(Ti)  <  SlfTj)) 

Insert(queue,  VwLock(T,,x),pos); 

else 

Insert(queue,pWait(T{,x),pos); 
before(Ti):=  before  {T^  u  {Tj}  kj  before  (Tj)  ; 
after(Tj)  :=  after {Tj)  u  {Tft  VJ after {T,) 

pos  :=  pos  - 1; 
if  (pos  =  0) 

Insert( queue  [xj,  pLock(Ti,x),pos): 


The  cases  above  arise  when  an  action  is  submitted.  When  a  lock  on  a  data  item  x  is 
released  and  the  action  at  the  front  of  queue[x]  does  not  have  a  dependent  lock,  plilx]  is  set  and 
Pilx]  submitted.  If  p/xj  had  held  a  virtual  lock,  all  locks  dependent  on  it  are  upgraded  to  real  or 
virtual  locks  depending  on  whether  they  were  at  the  front  of  their  respective  lock  queues  or  not. 


In  addition,  the  following  two  conditions  are  to  be  satisfied  by  the  transaction  manager; 

1)  A  transaction  is  allowed  to  commit,  even  if  virtual  writes  performed  by  the  transaction  have  not  been 
committed  to  stable  storage,  i.e  the  writes  are  still  on  some  queue[x]  waiting  to  set  a  real  lock  on  x. 

2)  Once  an  action  pj[x]  acquires  a  lock  on  a  data  item,  the  lock  is  not  released  until  Tj  commits  and  pj[x]  is 
performed  on  the  data  item  x  in  stable  storage.  Therefore,  in  most  cases,  all  the  locks  that  a  transaction 
holds  are  not  released  when  it  commits. 
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4.4  Deadlock  Detection  and  Resolution 


Hie  secure  two-phase  locking  protocol  is  not  free  from  deadlocks.  For  example,  consider  the  input 
schedule: 

T,  (SECRET)  :  r[x]  r[y] 

Tj  (UNCLASSIFED)  :  wly]  w[x] 

The  sequence  of  operations  performed  are  rlj[x]  ri[x]  WI2M  W2[y]  vwl2[x]  €2-  After  these  operations, 
deadlock  would  occur  because  rj[y]  waits  for  W2[y]  to  release  its  lock  and  vw2[x]  waits  for  rj[x]  to  release 
its  lock.  Deadlocks  can  be  detected  by  constructing  a  wait-for  graph  [Bern  87].  A  scheduler  recovers  from 
a  deadlock  by  aborting  one  of  the  transactions  in  the  cycle.  A  secure  scheduler  must  ensure  that  Recovery 
Security  is  not  violated  by  the  choice  of  a  victim.  This  can  be  guaranteed  by  aborting  a  transaction  at  the 
highest  access  class  in  the  cycle  detected  in  the  wait-for  graph. 

5.  An  Adaptive  Security  Policy 

A  detailed  performance  analysis  of  Secure  2PL  is  provided  in  [Son  94].  The  conclusion  was  that  it 
exhibits  a  much  better  response  time  characteristic  than  Secure  OCC.  Its  operating  region  (the  portion  of 
the  curve  before  the  saturation  point)  is  much  larger  than  that  of  Secure  OCC  (Figure  1).  Further,  staleness 
is  not  an  issue  in  Secure  2PL  as  with  Secure  MVTO.  However,  this  alone  does  not  suffice  when  timing 
constraints  are  present  on  transactions.  In  Secure  2PL,  transaction  scheduling  order  is  determined  purely 
by  the  order  in  which  transactions  acquire  locks.  No  conscious  effort  is  made  to  schedule  transactions 
according  to  their  priority,  or  according  to  how  close  a  transaction  is  to  meeting  its  deadline.  In  a  real-time 
database  system  this  is  unacceptable.  In  Section  3,  we  have  seen  that  priority-driven  scheduling  of  transac¬ 
tions  could  lead  to  security  violations.  It  is  our  claim  that  the  security  properties  have  to  be  sacrificed  to 
some  extent  to  ensure  a  certain  degree  of  deadline  cognizance. 

An  introduction  to  the  problem  of  covert  channels  was  given  in  Section  2.  A  covert  timing  channel  is 
opened  between  two  collaborating  transactions  -  one  at  a  higher  access  class  and  the  other  at  a  lower  access 
class  -  if  the  higher  access  class  transaction  can  influence  the  delay  seen  by  a  lower  access  class  transac¬ 
tion.  The  bandwidth  of  a  covert  channel  is  a  measure  of  how  easy  it  is  for  the  higher  access  class  transac¬ 
tion  to  control  the  delay  seen  by  the  lower  access  class  transaction.  If  there  is  a  great  degree  of  randomness 
in  the  system,  i.e.,  an  indeterminate  number  of  transactions  could  be  affecting  the  delay  that  the  higher 
access  class  transactions  wants  a  lower  access  class  transaction  to  experience,  then  the  bandwidth  is  low. 
On  the  other  hand,  if  the  higher  access  class  transaction  knows  that  the  lower  access  class  transaction  to 
which  it  wants  to  transmit  information  is  the  only  other  transaction  in  the  system,  then  the  bandwidth  is 
infinite.  Therefore,  when  security  has  to  be  sacrificed,  a  policy  that  keeps  the  bandwidth  of  the  resulting 
covert  channel  to  a  minimum  is  desirable.  To  ensure  this,  the  security  policy  has  to  be  adaptive,  i.e.,  deter¬ 
mining  whether  security  is  to  be  violated  or  not  when  a  conflict  arises  should  depend  on  the  current  state  of 
the  system  and  not  on  a  static,  predecided  property. 

Our  adaptive  policy  to  resolve  conflicts  between  lock  holding  and  lock  requesting  transactions  is  based 
on  past  execution  history.  Whenever  a  transaction  T|  requests  a  lock  on  a  data  item  x  on  which  another 
transaction  T2  holds  a  conflicting  lock,  there  are  two  possible  options: 

-  T|  could  be  blocked  until  T2  releases  the  lock. 

-  T2  could  be  aborted  and  the  lock  granted  to  T]. 
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If  Tj  were  at  a  higher  security  level  than  T2,  the  latter  option  would  be  a  violation  of  security.  However, 
if  Ti  has  greater  priority  than  T2,  then  the  latter  option  would  be  the  option  taken  by  a  real-time  concur¬ 
rency  control  approach.  In  our  approach,  we  strike  a  balance  between  these  two  conflicting  options  by 
looking  up  past  history.  A  measure  of  the  degree  to  which  security  has  been  violated  in  the  past  is  calcu¬ 
lated.  A  similar  measure  of  the  degree  to  which  the  real-time  constraints  have  not  been  satisfied  can  be 
obtained  from  the  number  of  deadlines  missed  in  the  past.  These  two  measures  are  compared  and  depend¬ 
ing  on  which  value  is  greater,  either  the  security  properties  are  satisfied  or  the  higher  priority  transaction  is 
given  the  right  to  execute. 

The  two  factors  that  are  used  to  resolve  a  conflict  are: 

-  Security  Factor  (SF):  (number  of  conflicts  for  which  security  is  maintained/  total  number  of  conflicts)  * 

Difference  in  security  level  between  the  two  conflicting  transactions. 

-  Deadline  Miss  Factor  (DMF):  number  of  transactions  that  missed  their  deadline/Total  number  of  transac¬ 

tions  committed 


Two  factors  are  involved  in  the  calculation  of  SF.  The  first  factor  is  the  degree  to  which  security  has 
been  satisfied  in  the  past,  measured  by  the  number  of  conflicts  for  which  security  has  been  maintained. 
Secondly,  we  also  assume  that  the  greater  the  difference  in  security  levels  between  the  transactions 
involved  in  the  conflict,  the  more  important  it  is  to  maintain  security.  DMF  is  determined  only  by  the  num¬ 
ber  of  deadline  misses  in  the  past.  Note  that  for  a  comparison  with  DMF,  (1  -  SF)  has  to  be  used,  since  (1  - 
SF)  is  a  measure  of  the  degree  to  which  security  has  been  violated.  Now,  a  simple  comparison  (1  -  SF)  > 
DMF  is  not  enough,  since  different  systems  need  to  maintain  different  levels  of  security.  Therefore,  we 
define  two  weighting  factors,  a  and  P  for  (1  -  SF)  and  DMF  respectively.  If  a  *  (1  —  SF)  >  P  *  DMF,  then 
for  the  conflict  under  consideration,  the  security  properties  are  more  important  and  therefore  the  conflict  is 
decided  in  favor  of  the  transaction  at  a  lower  access  class.  If  the  opposite  is  true,  then  the  transaction  with 
higher  priority  is  given  precedence.  Note  that  at  low  conflict  rates,  it  is  possible  to  satisfy  both  the  security 
and  the  real-time  requirements  simultaneously.  As  a  result  the  comparison  is  not  made  until  the  DMF 
reaches  a  certain  threshold  value  DMISS_THRESH.  The  parameters  DMISS_THRESH,  ot  and  p  can  be 
tuned  for  the  desired  level  of  security.  A  very  high  value  of  DMISS_THRESH  or  a  very  high  value  of  a 
compared  to  P  would  result  in  SF  being  maintained  at  1.0,  i.e.,  for  all  conflicts  the  security  properties  are 
satisfied.  A  very  high  value  of  P  compared  to  a  would  result  in  an  SF  value  of  0.0,  i.e.,  the  behavior  would 
be  identical  to  that  of  2PL-HP  [Abbo  92].  For  a  desired  value  of  SF  between  0  and  1 ,  the  values  of  a,  P  and 
DMISS_THRESH  would  have  to  be  tuned  based  on  the  arrival  rate  of  transactions. 

The  hybrid  protocol  is  defined  by  the  following  rules: 

If  a  conflict  between  a  lock  holding  transaction  Tj  and  a  lock  requesting  transaction  T2  arises,  the  con¬ 
flict  is  settled  using  the  following  rules: 

•  If  DMF  <  DMISSJTHRESH  then  follow  the  steps  taken  by  the  Secure  2PL  protocol 

•  Else  If  CL*  (1  -  SF)  >  p  *  DMF,  follow  the  steps  taken  by  the  Secure  2PL  protocol 

•  Else  break  the  conflict  in  favor  of  the  transaction  with  the  higher  priority 

6,  Performance  Evaluation 
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In  this  section,  we  present  the  results  of  our  performance  study  of  the  Adaptive  Secure  2PL  protocol  for 
a  wide  range  of  values  of  SF.  The  two  main  goals  of  our  performance  analysis  are: 

•  To  determine  miss  percentages  for  varying  transaction  arrival  rates  for  various  values  of  SF. 

•  Since  our  model  assumes  a  soft  deadline  system,  the  second  factor  that  has  been  measured  is  tardy 
time  -  the  difference  between  the  commitment  time  and  deadline  for  late  transactions. 

6.1  Simulation  Model 

Central  to  the  simulation  model  is  a  single-site  disk  resident  database  system  operating  on  shared-mem¬ 
ory  multiprocessors  [Lee  93].  The  system  consists  of  a  disk-based  database  and  a  main  memory  cache. 
The  unit  of  database  granularity  is  the  page.  When  a  transaction  needs  to  perform  an  operation  on  a  data 
item  it  accesses  a  page.  If  the  page  is  not  found  in  the  cache,  it  is  read  from  disk.  CPU  or  disk  access  is 
through  an  M/M/k  queueing  system,  consisting  of  a  single  queue  with  ‘k’  servers  (where  ‘k’  is  the  number 
of  disks  or  CPUs).  The  service  times  for  CPU  operations  and  disk  I/O  are  specified  as  model  parameters  in 
Table  1.  Since  we  are  concerned  only  with  providing  security  at  the  concurrency  control  level,  the  issue  of 
providing  security  at  the  operating  system  or  resource  scheduling  layer  is  not  considered  in  this  paper.  That 
is  the  reason  why  we  do  not  consider  a  secure  CPU/disk  scheduling  approach.  Our  assumption  is  that  the 
lower  layers  provide  the  higher  concurrency  control  layer  with  a  fair  resource  scheduling  policy. 

In  the  model  for  Adaptive  Secure  2PL,  the  execution  of  a  transaction  consists  of  multiple  instances  of 
alternating  data  access  requests  and  data  operation  steps,  until  all  the  data  operations  in  it  complete  or  it  is 
aborted.  When  a  transaction  makes  a  data  request,  i.e.,  lock  request  on  a  data  object,  the  request  must  go 
through  concurrency  control  to  obtain  a  lock  on  the  data  object.  Ifa*(l-SF)<p*  DMF,  then  if  the 
transaction’s  priority  is  greater  than  all  of  the  lock  holders,  the  holders  are  aborted  and  the  transaction  is 
granted  a  lock;  if  the  transaction’s  priority  is  lower,  it  waits  for  the  lock  holders  to  release  the  lock  [Abbo 
92].  However,  if  a  *  (1  —  SF)  >  P  *  DMF,  then  the  steps  taken  by  the  Secure  2PL  are  followed.  If  the 
request  for  a  lock  is  granted,  the  transaction  proceeds  to  perform  the  data  operation,  which  consists  of  a 
possible  disk  access  (if  the  data  item  is  not  present  in  the  cache)  followed  by  CPU  computation.  However, 
if  only  a  virtual  or  dependent  lock  is  granted,  the  transaction  only  does  CPU  computation,  since  the  opera¬ 
tion  should  only  be  performed  on  a  local  version.  If  the  request  for  the  lock  is  denied  (the  transaction  is 
blocked),  the  transaction  is  placed  into  the  data  queue.  When  the  waiting  transaction  is  granted  a  lock,  only 
then  can  it  perform  its  data  operation.  Also,  when  a  virtual  lock  for  an  operation  is  upgraded  to  a  real  lock, 
the  data  operation  requires  disk  access  and  CPU  computation.  At  any  stage,  if  a  deadlock  is  detected,  the 
transaction  to  be  aborted  to  break  the  deadlock  is  determined,  aborted  and  restarted.  When  all  the  opera¬ 
tions  in  a  transaction  are  completed,  the  transaction  commits.  Even  if  a  transaction  misses  its  deadline,  it  is 
allowed  to  execute  until  all  its  actions  are  completed. 

6.2  Parameters  and  Performance  Metrics 

Table  1  gives  the  names  and  meanings  of  the  parameters  that  control  system  resources.  The  parameters, 
CPUTime  and  DiskTime  capture  the  CPU  and  disk  processing  times  per  data  page.  Our  simulation  system 
does  not  explicitly  account  for  the  time  needed  for  data  operation  scheduling.  We  assume  that  these  costs 
are  included  in  CPUTime  on  a  per-data-object  basis.  The  use  of  a  database  cache  is  simulated  using  proba¬ 
bility.  When  a  transaction  attempts  to  read  a  data  page,  the  system  determines  whether  the  page  is  in  cache 
or  disk  using  the  probability  BufProb.  If  the  page  is  determined  to  be  in  cache,  the  transaction  can  continue 
processing  without  disk  access.  Otherwise  disk  access  is  needed. 

Table  2  summarizes  the  key  parameters  that  characterize  system  workload  and  transactions.  Transac- 
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tions  arrive  in  a  Poisson  stream,  i.e.,  their  inter-arrival  rates  are  exponentially  distributed.  The  ArriRate 
parameter  specifies  the  mean  rate  of  transaction  arrivals.  The  number  of  data  objects  accessed  by  a  transac¬ 
tion  is  determined  by  a  normal  distribution  with  mean  TranSize,  and  the  actual  data  objects  to  be  accessed 
are  determined  uniformly  from  the  database. 

The  assignment  of  deadlines  to  transactions  is  controlled  by  the  parameters  MinSlack  and  MaxSlack, 
which  set  a  lower  and  upper  bound,  respectively,  on  a  transaction’s  slack  time.  We  use  the  formula  for 
deadline-assignment  to  a  transaction. 

Deadline  =  AT  +  \JnifoTm{MinSlack,MiixSlack)  *  ET 

AT  and  ET  denoting  the  arrival  time  and  execution  time,  respectively.  The  execution  time  of  a  transac¬ 
tion  used  in  this  formula  is  not  an  actual  execution  time,  but  a  time  estimated  using  the  values  of  parame¬ 
ters  TranSize,  CPUTime  and  DiskTime.  The  priorities  of  transactions  are  decided  by  the  Earliest  Deadline 
First  policy. 

The  primary  performance  metric  used  is  miss  percentage,  which  is  the  ratio  of  the  number  of  transac¬ 
tions  that  do  not  meet  their  deadline  to  the  total  number  of  transactions  committed.  The  second  perfor¬ 
mance  metric  is  tardy  time. 

6.3  Experiments  and  Results 

An  event-based  simulation  framework  was  written  in  ‘C’.  For  each  experiment,  we  ran  the  simulation 
with  the  same  parameters  for  6  different  random  number  seeds.  Each  simulation  run  was  continued  until 
200  transactions  at  each  access  class  were  committed.  For  each  run,  the  statistics  gathered  during  the  first 
few  seconds  were  discarded  in  order  to  let  the  system  stabilize  after  an  initial  transient  condition.  For  each 
experiment  the  required  performance  measure  was  measured  over  a  wide  range  of  workload.  All  the  data 
reported  in  this  paper  have  90%  confidence  intervals,  whose  endpoints  are  within  10%  of  the  point  esti¬ 
mate. 

6.3.1  Experiment  1:  Secure  2PL  vs  Secure  OCC  vs  Secure  MVTO 

The  first  experiment  was  conducted  to  prove  that  the  average  case  performance  of  Secure  2PL  is  better 
than  that  of  the  other  existing  secure  concurrency  control  algorithms.  Note  that  good  average  case  perfor¬ 
mance  is  also  essential  for  a  real-time  system.  A  slow  system  cannot  be  expected  to  meet  timing  con¬ 
straints.  In  this  experiment,  the  response  times  of  Secure  2PL,  Secure  OCC  and  Secure  MVTO  at  each 
security  level  were  measured  for  varying  arrival  rates.  The  resulting  graphs  are  shown  in  Figures  I  and  2. 
At  low  arrival  rates,  the  response  times  are  more  or  less  the  same  for  all  three  approaches.  This  is  because 
the  contention  levels  are  low  and  majority  of  time  is  spent  in  disk  access  and  CPU  access  rather  than  in 
resource  queues,  lock  queues  or  transaction  aborts.  As  the  arrival  rate  increases  the  impact  of  these  factors 
increases,  and  depending  on  how  much  they  increase  in  each  concurrency  control  approach,  the  perfor¬ 
mance  varies.  In  Secure  OCC,  the  saturation  point  is  reached  much  earlier  than  in  Secure  2PL  and  Secure 
MVTO.  As  the  arrival  rate  increases,  the  contention  level  for  data  items  increases.  As  a  result,  when  a 
higher  access  class  transaction  reaches  its  validation  stage,  invariably  it  would  have  conflicted  with  a 
transaction  at  a  lower  access  class  and  would  therefore  have  to  be  aborted  and  restarted.  It  was  found  that 
the  system  reached  a  stage  where,  at  the  highest  access  class,  transactions  were  repeatedly  being  aborted 
and  restarted,  resulting  in  the  steep  increase  in  response  time  at  the  saturation  point.  Now,  since  transac¬ 
tions  are  not  being  committed  while  arrival  rate  is  unchanged,  the  net  number  of  active  transactions  keeps 
increasing,  increasing  contention  for  the  finite  resources.  It  is  because  of  this  phenomenon  that  the 
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Table  1:  System  Resource  Parameters 


Parameter 

Meaning 

Base  Value 

DBSize 

Number  of  data  pages  in  database 

350 

NumCPUs 

Number  of  processors 

2 

NumDisks 

Number  of  disks 

4 

CPUTime 

CPU  time  for  processing  an  action 

15  msec 

DiskJime 

Disk  service  time  for  an  action 

25  msec 

BufProb 

Prob.  of  a  page  in  memory  buffer 

0.5 

NumSecLevels 

Num.  of  security  levels  supported 

6 

Table  2:  Workload  Parameters 


Parameter 

Meaning 

Base  Value 

ArriRate 

Mean  transaction  arrival  rate 

- 

TranSize 

Average  Transaction  Size 

6 

RestartDelay 

Mean  overhead  in  restarting 

1  msec 

MinSlack 

Minimum  slack  factor  • 

2 

MaxSlack 


Maximum  slack  factor 


8 


response  time  for  lower  access  class  transactions  increases  also  at  the  saturation  point.  The  performance 
margin  of  Secure  2PL  at  level  0  over  Secure  2PL  at  level  5  is  small,  indicating  a  greater  measure  of  fair¬ 
ness  than  in  Secure  OCC.  In  addition,  the  saturation  point  is  reached  at  a  much  higher  arrival  rate  in  Secure 
2PL  than  in  Secure  OCC.  Of  course,  the  response  time  graph  for  Secure  MVTO  is  the  best,  since  no  trans¬ 
actions  are  blocked  or  aborted.  The  performance  margin  of  Secure  MVTO  at  level  0  over  Secure  MVTO  at 
level  5  is  negligibly  small.  The  rate  of  increase  in  response  time  after  the  saturation  point  is  also  much  less 
than  that  of  both  Secure  OCC  and  Secure  2PL.  However,  in  Secure  MVTO,  the  good  response  time  is  off¬ 
set  by  an  unacceptable  staleness  factor.  This  is  all  the  more  critical  in  a  real-time  environment,  where  data 
could  have  temporal  constraints  associated  with  them. 

6.3.2  Experiment  2:  Adaptive  Secure  2PL  -  Miss  Percentage 

In  this  experiment,  the  miss  percentages  for  Adaptive  Secure  2PL  are  measured  for  three  different  set¬ 
tings  of  the  SF  values  -  fully  secure  (SF  =  1.0),  no  security  (SF  =  0.0)  and  partially  secure  (SF  =  0.5).  The 
resulting  graph  is  shown  in  Figure  3.  Since  we  are  considering  a  real-time  database  system,  we  restrict 
attention  to  the  portion  of  the  graph  where  miss  percentages  are  less  than  10%.  The  performance  after  the 
saturation  point  is  not  an  issue.  As  is  to  be  expected,  2PL-HP  has  the  lowest  miss  percentage,  with  the 
curve  for  2PL  (SF=0.5)  falling  between  2PL-HP  and  Secure  2PL.  However,  one  does  not  see  a  progressive 
decrease  in  miss  percentage  from  SF=l.O  to  SF=0.0.  The  miss  percentage  increases  from  SF=1.0  to 
SF=0.65,  but  subsequently  decreases  at  SF=0.5  up  to  SF=0.0.  This  is  because  at  higher  values  of  SF  (0.65 
to  1 .0),  the  number  of  actions  scheduled  according  to  priority  is  very  low.  However,  since  the  system  is  not 
fully  secure,  some  transactions  are  being  aborted,  when  security  needs  to  be  violated  by  the  Adaptive  2PL 
protocol.  The  problem  is  that  the  former  factor  does  not  offset  the  latter  factor,  resulting  in  increased  miss 
percentage.  As  SF  decreases,  the  former  factor  increases,  resulting  in  more  transactions  meeting  their 
deadline. 

6.3.3  Experiment  3:  Adaptive  Secure  2PL  -  Tardy  Time 

In  this  experiment,  the  average  tardy  times  for  Adaptive  Secure  2PL  are  measured  for  three  different 
settings  of  the  SF  values  -  fully  secure  (SF  =  1.0),  no  security  (SF  =  0.0)  and  partially  secure  (SF  =  0.5). 
The  resulting  graph  is  shown  in  Figure  4.  The  results  obtained  conform  with  the  results  obtained  for  the 
miss  percentage  calculation.  The  tardy  time  is  maximum  for  Secure  2PL,  with  the  curve  for  Adaptive  2PL 
(SF  =  0.5)  falling  between  that  of  Secure  2PL  and  2PL-HP. 

7.  Conclusions 

In  this  paper,  we  have  presented  an  approach  to  scheduling  transactions  to  meet  their  timing  constraints 
in  a  secure  database.  Our  simulation  results  substantiate  our  claim  that  an  adaptive  security  policy  that  sac¬ 
rifices  the  security  properties  to  some  extent  can  significantly  improve  the  deadline  miss  performance.  The 
work  described  in  this  paper  is  more  a  direction  for  future  research  than  a  concrete  solution  to  the  problem 
of  secure  real-time  concurrency  control.  There  are  a  number  of  issues  that  need  to  be  looked  into.  First  of 
all,  a  proper  characterization  of  the  bandwidth  of  a  covert  channel  that  can  arise  given  a  particular  value  of 
SF  needs  to  be  derived.  Applications  might  express  a  desired  level  of  security  in  terms  of  a  maximum 
admissible  bandwidth  of  a  potential  covert  channel.  Unless  there  is  a  way  of  determining  to  what  extent  a 
security  policy  satisfies  the  security  properties,  one  cannot  determine  whether  the  policy  is  suitable  for  the 
application  or  not.  Secondly,  in  this  paper  we  have  considered  a  simple  tradeoff  between  deadline  miss 
percentage  and  security.  A  tradeoff  could  also  have  been  made  between  alternative  factors  depending  on 
the  application.  Thirdly,  we  have  restricted  ourselves  to  a  soft  deadline  system  with  no  overload  manage¬ 
ment  policy.  It  would  be  interesting  to  see  how  a  policy  to  screen  out  transactions  that  are  about  to  miss 
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their  deadline  would  affect  performance.  Finally,  in  this  paper,  we  have  restricted  ourselves  to  the  problem 
of  real-time  secure  concurrency  control  in  a  database  system.  Some  of  the  other  issues  that  need  to  be  con¬ 
sidered  in  designing  a  comprehensive  real-time  multilevel  secure  database  system  (MLS/RTDBMS)  are 
dealt  with  in  [Son  93].  Various  types  of  MLS/RTDBMSs  need  to  be  identified  and  architectures  and  algo¬ 
rithms  developed  for  each  type  of  system.  Tradeoffs  need  to  be  made  between  security,  timeliness  and  con¬ 
sistency  on  a  case-by-case  basis. 
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Abstract 

Previous  work  in  real-time  database  management 
systems  (RT-DBMS)  has  primarily  based  on  simula¬ 
tion,  This  paper  discusses  how  current  real-time  tech¬ 
nology  has  been  applied  to  architect  an  actual  RT- 
DBMS  on  a  real-time  microkernel  operating  system. 
A  real  RT-DBMS  must  confront  many  practical  issues 
which  simulations  typically  ignore:  race  conditions y 
concurrency,  and  asynchrony.  The  challenge  of  con¬ 
structing  a  RT-DBMS  is  divided  into  three  basic  prob¬ 
lems:  dealing  with  resource  contentiony  dealing  with 
data  contention,  and  enforcing  timing  constraints.  In 
this  paper,  we  present  our  apprvaches  to  each  prob¬ 
lem. 


1  Introduction 

As  real-time  applications  grow  more  and  more  com¬ 
plex,  so  do  the  ways  in  which  they  maintain  and  access 
data.  As  programs  are  required  to  manage  larger  and 
large  volumes  of  data,  they  typically  turn  away  from 
application-specific  solutions  and  seek  general,  adapt¬ 
able,  modular  ways  to  manage  data.  Conventional 
systems  use  Database  Management  Systems  (DBMS) 
to  achieve  these  ends,  and  DBMS  technology  is  well- 
understood.  Despite  all  of  its  features,  however,  a  con¬ 
ventional  DBMS  is  not  quite  capable  of  meeting  the 
demands  of  a  real-time  system.  Typically,  its  goals 
are  to  maximize  transaction  throughput,  minimize  re¬ 
sponse  time,  and  provide  some  degree  of  fairness.  A 
RT-DBMS,  however,  must  adopt  goals  which  are  con¬ 
sistent  with  any  real-time  system:  providing  the  best 
service  to  the  most  critical  transactions  and  ensuring 
some  degree  of  predictability  in  transaction  process¬ 
ing. 

'This  work  was  supported  in  part  by  ONR. 


The  StarBase  RT-DBMS  is  an  attempt  to  merge 
conventional  DBMS  functionality  with  real-time  tech¬ 
nology.  StarBase  supports  the  relational  database 
model  and  understands  a  simple  SQL-like  query  lan¬ 
guage.  The  DBMS  maintains  a  centralized  server 
to  which  local  or  remote  clients  submit  transactions. 
Transactions  may  execute  concurrently  and  serializ- 
ability  is  the  correctness  criterion.  In  addition  to  this 
conventional  functionality,  StarBase  seeks  to  minimize 
the  number  of  high-priority  transactions  that  miss 
their  deadlines.  StarBase  uses  no  a  priori  information 
about  transaction  workload  and  discards  tardy  trans¬ 
actions  at  their  deadline  points.  In  order  to  realize 
many  of  these  goals,  StarBase  is  constructed  on  top  of 
RT-Mach,  a  real-time  operating  system  developed  at 
Carnegie  Mellon  University  [11].  StarBase  differs  from 
previous  RT-DBMS  work  [1,  2,  3]  in  that  a)  it  relies  on 
a  real-time  operating  system  which  provides  priority- 
based  scheduling  and  time-based  synchronization,  and 
b)  it  deals  explicitly  with  data  contention  and  dead¬ 
line  handling  in  addition  to  transaction  scheduling,  the 
traditional  focus  of  simulation  studies. 

There  are  essentially  three  problems  with  which 
RT-DBMSs  must  deal:  resolving  resource  contention, 
resolving  data  contention,  and  enforcing  timing  con¬ 
straints.  As  with  other  real-time  systems,  tasks  to 
be  performed  are  stratified  according  to  their  relative 
importance  to  the  system.  Priority  combines  this  rel¬ 
ative  importance  with  task  timing  constraints  to  pro¬ 
vide  a  means  to  decide  which  of  many  tasks  should 
be  scheduled  at  any  given  moment.  The  intent  is  to 
always  grant  the  highest  priority  tasks  access  to  re¬ 
sources  (CPU,  critical  sections,  etc,).  Similarly,  Star- 
Base  considers  each  transaction  a  task  in  its  own  right 
and  seeks  to  provide  the  best  service  to  the  highest 
priority  transactions.  The  rest  of  this  paper  is  de¬ 
voted  to  addressing  how  StarBase  allocates  resources 
to  the  highest  priority  transactions  and  how  it  enforces 
timing  constraints. 


Figure  1:  StarBase  Server  Architecture 


2  Database  Overview 

The  StarBase  DBMS  is  organized  as  a  multi¬ 
threaded  server  as  shown  in  Figure  1.  It  is  assumed 
that  database  clients  are  physically  disparate  from  the 
server,  so  they  pass  messages  to  communicate  with  the 
DBMS  server.  Transaction  requests  are  sent  via  RT- 
Mach’s  Inter-Process  Communication  (IPC)  mecha¬ 
nism  and  are  queued  at  the  server’s  ser\ice  port.  RT- 
Mach  pro\ddes  a  naming  service  with  which  StarBase 
registers  its  service  port  during  initialization.  Clients 
look  up  the  service  port  by  querying  the  name  server 
with  StcirBase’s  well-known  name. 

When  a  request  enters  service,  a  transaction  man¬ 
ager  thread  of  execution  is  charged  with  ensuring  it 
is  properly  processed.  The  transaction  manager  ex¬ 
ecutes  the  appropriate  operations  (e.g.,  read,  write) 
as  dictated  by  the  content  of  the  request.  At  the 
start  of  transaction  processing,  the  transaction  man¬ 
ager  starts  a  deadline  manager  thread,  whose  behavior 
is  discussed  in  Section  5,  to  enforce  the  transaction’s 
deadline.  A  transaction  needs  certain  resources  to  ex¬ 
ecute,  including  mechanisms  to  acquire  memory,  read 
and  write  data  from  relations,  and  ensure  that  data  re¬ 
mains  consistent.  StaxBase’s  three  resource  managers 
provide  these  services:  the  Small  Memory  Manager 
(MemMgr),  the  Relation  I/O  Manager  (RIO Mgr),  and 
the  Concurrency  Controller  (CCMgr).  Each  resource 
manager  must  ensure  that  transactions  access  their  re¬ 


sources  in  a  consistent  and  orderly  fashion.  To  prevent 
mayhem,  two  of  the  resource  managers  are  organized 
as  monitors  to  synchronize  the  actions  of  different 
transactions.  The  services  of  the  RIOMgr,  however, 
are  explicitly  synchronized  by  the  CCMgr. 

StarBase  uses  optimistic  concurrency  control  to  en¬ 
sure  data  consistency,  allowing  transactions  to  proceed 
unhindered  until  they  are  ready  to  apply  their  updates 
to  the  database.  The  particulars  of  the  concurrency 
control  algorithm  are  detailed  in  Section  4. 


3  Resource  Contention  and  Transac¬ 
tion  Scheduling 

For  decades  the  major  trend  in  computing  has  been 
to  increase  efficiency  by  sharing  resources.  By  provid¬ 
ing  the  abstraction  of  processes  (threads  of  execution) 
and  a  single  software  entity  to  control  access  to  re¬ 
sources  such  as  the  CPU,  memory,  and  disk,  comput¬ 
ers  provide  the  illusion  of  the  concurrent  execution  of 
different  tasks  in  an  orderly  fashion.  The  ultimate 
arbiter  of  resources  is  the  operating  system,  which  is 
charged  with  resolving  which  thread  of  execution  gets 
a  particular  resource  at  any  given  time.  Since  they  are 
designed  to  interact  with  humans,  the  goals  of  con¬ 
ventional  systems,  by  and  large,  are  to  achieve  fair¬ 
ness  and  minimize  response  time.  Real-time  systems, 
however,  are  designed  for  embedded  environments  and 
require  quick  and  predictable  behavior  in  response  to 
external  mechanical  and  electrical  stimuli.  Tasks  that 
a  real-time  system  must  perform  are  ranked  accord¬ 
ing  to  their  importance  and  the  most  critical  tasks  are 
given  the  best  access  to  resources  to  ensure  the  highest 
probability  of  completing  on  time. 

As  with  any  application,  the  StarBase  RT-DBMS 
is  highly  reliant  on  its  native  operating  system,  RT- 
Mach,  to  provide  the  priority-cognizant  services  nec¬ 
essary  for  real-time  resource  scheduling.  RT-Mach’s 
services  in  turn  are  based  on  two  major  ideas  (among 
others)  which  have  been  developed  to  ensure  the  allo¬ 
cation  of  resources  to  more  important  tasks  in  real¬ 
time  systems.  Those  ideas  are  priority-based  CPU 
scheduling  [7]  and  the  Basic  Priority  Inheritance  Pro¬ 
tocol  (BPI)  [9]  for  non-preemptible  resources.  With 
both  ideas,  tasks  to  be  performed  are  ranked  by  their 
relative  priorities  (a  function  of  their  criticality  and/or 
feasibility),  and  the  highest  priority  tasks  are  granted 
access  to  the  resource  in  question.  RT-Mach  provides 
several  priority-based  scheduling  regimes,  including 
Fixed  Priority,  Earliest  Deadline  First,  Rate  Mono¬ 
tonic,  and  Deadline  Monotonic.  RT-Mach’s  real-time 


thread  model  [11]  distinguishes  real-time  threads  of 
execution  from  ordinary  ones,  requiring  the  explicit 
specification  of  timing  constraints  and  criticality  on 
a  per-thread  basis.  The  timing  and  priority  informa¬ 
tion  is  then  used  as  input  to  the  RT-Mach  scheduler. 
RT-Mach  also  has  striven  to  implement  priority-based 
resource  scheduling  through  its  interprocess  communi¬ 
cation  (RT-IPC)  [5]  and  thread  synchronization  (RT- 
Sync)  [10]  facilities.  RT-Mach  implements  BPI  itself 
as  a  combination  of  priority  queuing  and  priority  in¬ 
heritance.  When  a  thread  blocks  on  a  mutex  variable 
or  when  a  message  cannot  be  immediately  received  be¬ 
cause  all  potential  receivers  are  busy,  RT-Mach  queues 
the  waiting  thread  or  message  in  priority  order  and 
then  boosts  the  priority  of  the  thread  inside  the  critical 
section  or  the  priority  of  one  of  the  potential  receivers 
in  accordance  with  the  BPI  protocol. 

StarBase  employs  RT-Mach’s  priority-based  CPU 
and  BPI  resource  scheduling  in  several  ways:  to  de¬ 
termine  the  transaction  service  order,  to  provide  high- 
priority  transactions  the  means  to  progress  faster 
than  low-priority  transactions,  and  to  provide  priority- 
consistent  access  to  facilities  such  as  the  Small  Mem¬ 
ory  Manager  and  Concurrency  Controller.  For  pur¬ 
poses  of  uniformity.  StarBase  adopts  the  same  data 
type  that  RT-Mach  uses  to  convey  priorities,  facili¬ 
tating  the  straightforward  translation  of  StarBase  to 
RT-Mach  priorities.  Since  the  priority  data  type, 
rt„priorit:y..t.  includes  a  wide  range  of  criticality 
and  timing  information,  major  changes  in  schedul¬ 
ing  policy  (e.g.,  Fixed  Priority  to  Earliest  Deadline 
First)  are  reduced  to  simple  changes  in  the  functions 
which  compare  priorities  (e.g.,  changing  the  compar¬ 
ison  of  criticalities  to  one  of  deadlines)  without  any 
change  in  the  client/server  interface.  StarBase  itself 
must  make  priority-based  decisions  (e.g.,  concurrency 
control),  so  its  priority-based  comparisons  involve  pri¬ 
orities  expressed  as  rt.,priority-.t-typed  values.  Of 
course,  which  policy  is  most  appropriate  differs  from 
application  to  application,  so  the  policy  to  be  used  is 
left  as  a  compile-time  constant.  Naturally,  StarBase 
must  use  a  consistent  transaction  scheduling  policy 
across  all  of  its  priority-based  decisions. 

3.1  Transaction  Service  Order 

Since  performance  ultimately  degrades  as  the  num¬ 
ber  of  threads  of  execution  in  a  system  increases,  and 
lazy  allocation  of  resources  adds  unpredictability  to 
the  system,  StarBase  maintains  only  a  fixed  number 
of  preallocated  transaction  manager  threads.  At  the 
same  time,  since  the  StarBase  DBMS  has  no  o  priori 
knowledge  of  transaction  workload,  more  transactions 


may  be  submitted  to  the  DBMS  than  it  can  handle  at 
any  given  time.  In  order  to  throttle  the  flow  in  such 
circumstances,  StarBase  needs  a  mechanism  to  decide 
which  requests  to  admit  into  service,  and  RT-Mach’s 
RT-IPC  facilities  do  just  that  in  a  convenient  and 
priority-cognizant  manner.  To  submit  a  transaction 
to  the  StarBase  DBMS,  a  client  places  the  transaction 
instructions  and  priority  information  into  a  message 
and  uses  RT-IPC  to  send  the  message  to  the  DBMS 
server.  Since  RT-IPC  queues  incoming  messages  in 
priority  order,  the  next  available  transaction  manager 
receives  the  next  highest  priority  unreceived  message. 
Requests  are  therefore  served  in  priority  order  and 
only  the  highest  priority  outstanding  requests  are  in 
service  at  any  given  time.  If  a  high  priority  transac¬ 
tion  request  cannot  be  serviced  immediately  because 
all  transaction  manager  threads  are  busy  serving  some 
lower  priority  requests,  RT-IPC ’s  priority  inheritance 
expedites  one  or  more  of  the  transaction  managers  so 
that  the  high  priority  request  enters  service  at  a  time 
bounded  by  the  minimum  of  the  in-service  transaction 
deadlines. 

Once  transactions  enter  service,  StarBase  needs 
to  ensure  that  high  priority  transactions  progress  as 
quickly  as  possible.  Since  transactions  require  real¬ 
time  execution,  StarBase  creates  one  real-time  thread 
for  each  transaction  manager  and  relies  on  RT-Mach’s 
real-time  CPU  scheduling  to  schedule  them.  Transac¬ 
tion  manager  priorities  are  not  specified  explicitly  by 
StarBase,  however.  Each  obtains  the  correct  priority 
assignment  automatically  upon  receipt  of  a  new  trans¬ 
action  via  RT-IPC ’s  priority  handoff  mechanism  [5]. 

3.2  Memory  Manager 

Transactions,  depending  on  the  nature  of  their  op¬ 
erations,  require  some  dynamic  allocation  of  memory 
during  their  execution.  StarBase  maintains  a  Small 
Memory  Manager  to  allocate  and  manage  dynamic 
memory.  Since  transaction  managers  of  different  pri¬ 
orities  may  attempt  to  use  it  simultaneously,  entry 
into  the  Small  Memory  Manager  is  guarded  by  a  real¬ 
time  mutex  variable  to  avoid  the  priority  inversion 
problem  and  to  ensure  the  heap  is  accessed  in  mutual 
exclusion.  To  provide  (relatively)  predictable  access 
to  memory  allocated  through  the  manager,  the  heap 
is  wired  so  that  it  cannot  be  paged  out  of  physical 
memory. 

3.3  Concurrency  Controller 

Although  the  StarBase  concurrency  controller  is  re¬ 
sponsible  for  resolving  contention  at  a  higher  level 


(i.e.,  data  contention),  it  still  relies  on  RT-Mach  to 
provide  basic  synchronization  and  avoid  the  priority 
inversion  problem.  In  particular,  the  concurrency  con¬ 
troller  must  keep  its  own  data  structures  consistent 
and  ensure  that  transaction  commits  occur  without 
interference.  As  such  the  concurrency  controller  is  or¬ 
ganized  as  a  monitor,  with  a  single  real-time  mutex 
variable  for  the  monitor  lock,  and  one  real-time  con¬ 
dition  variable  for  each  transaction  manager.  The  pre¬ 
cise  function  of  the  concurrency  controller  is  detailed 
in  the  next  section. 


4  Data  Contention  and  Concurrency 
Control 

In  addition  to  resources  such  as  the  CPU  and  mem¬ 
ory',  transactions  compete  for  access  to  the  data  stored 
in  the  database.  To  obtain  reasonable  performance,  a 
DBMS  must  allow  multiple  transactions  to  access  data 
concurrently  while  requiring  that  the  outcome  appears 
as  if  it  were  the  result  of  a  serial  execution  of  those 
transactions.  Satisfying  these  two  goals  produces  a 
problem  which  is  quite  distinct  from  ordinary  con¬ 
tention  for  operating  system  resources:  contention  for 
data.  To  resolve  data  conflicts,  StarBase  uses  a  con¬ 
currency  control  implementation  which  draws  heavily 
from  the  work  of  two  research  groups.  First,  Har- 
itsa  reasoned  that  optimistic  concurrency  control  can 
outperform  lock-based  algorithms  in  a  firm  real-time 
setting  [2].  He  then  developed  a  real-time  optimistic 
concurrency  control  method,  WAIT-X(S),  which  he 
found  empirically  superior,  over  a  wide  range  of  re¬ 
source  a\'ailability  and  system  workload  levels,  to  a 
pre\dously  proposed  real-time  lock-based  concurrency 
control  method  called  2PL-HP  [2].  Second,  Lee  and 
Son  devised  an  improvement  to  the  conflict  detection 
of  optimistic  concurrency  control  in  general,  which 
StarBase  integrates  with  Haritsa’s  WAIT-X(S)  [6]. 

4.1  WAIT-X(S) 

WAIT-X  is  optimistic,  using  prospective  conflict  de¬ 
tection  and  priority-based  conflict  resolution.  WAIT- 
X’s  conflict  detection  is  prospective  in  the  sense  that  it 
looks  for  conflicts  between  the  validator  and  transac¬ 
tions  which  may  commit  sometime  in  the  future  (i.e., 
running  transactions).  Prospective  conflict  detection 
is  also  referred  to  as  forward  validation.  The  atten¬ 
dant  advantages  of  the  prospective  method  are  that 
potential  conflictors  are  readily  identifiable,  dataset 
comparisons  are  simplified,  and  conflicts  are  detected 


much  earlier  in  the  execution  history.  Real-time  op¬ 
timistic  methods  are  precluded,  however,  from  ret¬ 
rospective  (or  backward  validation)  conflict  detection, 
which  compares  the  validator  to  transactions  which 
committed  in  the  recent  past.  Since  all  the  transac¬ 
tions  which  conflict  with  a  validator  have  committed, 
there  is  oiJy  one  outcome  in  the  face  of  irreconcilable 
conflict:  abortion  of  the  validator  regardless  of  its  pri¬ 
ority  relative  to  its  conflictors.  Prospective  conflict 
detection,  on  the  other  hand,  allows  the  concurrency 
control  to  choose  between  aborting  the  validator  or  all 
of  its  conflictors  in  a  priority-cognizant  manner. 

When  WAIT-X  detects  conflicts  between  a  valida¬ 
tor  and  some  running  transactions,  it  can  choose  one 
of  three  outcomes  for  the  validator.  It  may  abort  the 
validator,  it  may  commit  the  validator  and  abort  the 
conflictors,  or  it  may  delay  the  validator  slightly  in 
the  hope  that  conflicts  resolve  themselves  in  a  favor¬ 
able  way.  Which  course  of  action  to  take  is  a  func¬ 
tion  of  the  priorities  of  the  validator  and  conflictors. 
In  particular,  Hcuritsa  divides  the  conflictors  into  two 
sets:  those  conflictors  with  higher  priority  than  the 
validator  (CHP),  and  those  with  lower  priority  (CLP). 
WAIT-X  blocks  the  validator  until  the  CHP  transac¬ 
tions  comprise  less  than  a  critical  portion,  X%,  of  the 
conflict  set: 

while  (  CHP  transactions  in  the  conflict  set 
and  CHP  transactions  comprise  greater 
than  X%  of  the  conflict  set  )  do 
wait: 

end 

abort  the  conflict  set; 

commit  the  validator; 

Haritsa  found  experimentally  that  low  values  of 
X  tend  to  minimize  the  deadline  miss  ratio  for  light 
loads,  and  high  values  of  X  tend  to  minimize  the  dead¬ 
line  miss  ratio  for  heavy  loads.  He  established  X  = 
50%  as  the  threshold  value  which  minimizes  the  over¬ 
all  deadline  miss  ratio,  but  applications  which  require 
minimization  of  the  highest-priority  deadline  miss  ra¬ 
tio  must  use  a  greater  value  for  X. 

The  final  aspect  of  the  WAIT-X  method  deals  with 
handling  the  abort  of  the  transaction  should  WAIT-X 
block  it  until  its  deadline.  Haritsa  claims  that  trans¬ 
actions  which  run  up  against  their  deadlines  while 
waiting  can  either  be  immediately  sacrificed  by  abort¬ 
ing  (WAJT-X(S))  or  committing  (WAIT-X(C)).  Sac¬ 
rifice  is  preferred  over  commit  since  waiters  are  more 
likely  to  be  lower  priority  than  most  of  their  conflic¬ 
tors.  More  importantly,  however,  commission  at  the 
deadline  point  would  effectively  extend  the  execution 
of  a  transaction  past  its  deadline,  so  WAIT-X(C)  is 


not  practical  for  systems  requiring  firm  real-time  con¬ 
straints  such  as  StarBase. 

4.2  WAIT-X(S)  Implementation 

The  StarBase  concurrency  control  uiut  imple¬ 
ments  Haritsa’s  WAIT-X  as  a  monitor  and  is  a 
more  active  entity  than  other  typical  concurrency 
controllers.  The  Concurrency  Control  Manager 
(CCMgr)  opens  and  closes  relations  on  behalf  of  ex¬ 
ecuting  transactions,  performs  write- throughs  to  the 
database,  handles  asynchronous  aborts,  and  elimi¬ 
nates  a  potential  race  condition  between  the  com¬ 
mission  of  a  transaction  and  the  expiration  of  its 
deadline.  Transaction  managers  use  the  six  ser¬ 
vices  pro\dded  by  the  CCMgr  (RegistexTransaction, 
RegisterRelationReference,  UpdateReadSet/tfriteSet, 
Validate,  Deadline  Abort,  and  AbortSelf)  by  calling 
the  corresponding  monitor  entry  procedure.  Each 
monitor  entry  procedure  locks  the  CCMgr  monitor 
lock  to  gain  access  to  the  monitor  and  unlocks  the 
monitor  lock  when  exiting.  The  monitor  lock  itself  is 
implemented  as  an  RT-Mach  mutex  \’ariable  to  con¬ 
trol  priority  inversion  between  contending  transaction 
managers.  Once  inside  the  monitor,  of  course,  opera¬ 
tions  proceed  in  a  mutually  exclusive  fashion. 

Although  on  paper  WAIT-X  consists  of  a  simple 
test  to  determine  whether  a  transaction  waits  or  com¬ 
mits,  in  practice,  the  test  is  actually  a  trigger  whose 
truth  value  can  change  at  any  instant  as  transactions 
enter  (by  reading  relations)  and  exit  (by  aborting)  the 
validator’s  conflict  set.  The  CCMgr  is  a  synchronous 
modification  of  the  asynchronous  WAIT-X  test,  where 
the  validation  state  corresponds  to  the  testing  the  trig¬ 
ger,  the  wait  state  corresponds  to  the  loop  body,  and 
the  committed  state  corresponds  to  the  statements 
after  the  while  loop.  Note  that  validators  may  be 
aborted  while  in  the  wait  state  either  due  to  the  com¬ 
mitment  of  other  validators  or  due  to  the  expiration 
of  the  validator’s  deadline. 

As  pre\’iously  mentioned,  the  composition  of  a  val¬ 
idator’s  conflict  set  may  change  from  instant  to  in¬ 
stant.  The  most  frequent  case,  when  a  running  trans¬ 
action  ad^^ces  in  its  read-  or  writeset,  is  expensive 
to  check  because  of  its  frequency  and  because  of  the 
size  of  the  read- /writeset  data  structures.  The  CCMgr 
limits  checking  the  trigger  condition  to  cases  where  it 
is  reasonably  sure  conflict  sets  have  changed:  when 
a  transaction  enters  validation  for  the  first  time  and 
when  a  transaction  aborts.  Note  that  in  this  scheme  a 
particular  transaction’s  wait  in  the  CCMgr  is  strictly 
bounded  by  its  deadline  and  waiting  transactions  retry 
validation  by  the  earliest  deadline  of  all  transactions  in 


Figure  2:  WAIT-X(S)  State  Diagram 

the  system  (subject  to  the  availability  of  the  processor 
to  the  transaction  with  earliest  deadline).  In  order  to 
give  precedence  to  the  highest  priority  transactions,  all 
waiting  transactions  retry  validation  in  priority  order 
(Figure  2). 

As  is  typical,  reads  and  writes  are  recorded  in 
bitmaps  for  each  relation  a  transaction  references. 
Comparison  of  the  read-  and  writesets  of  transactions 
during  conflict  identification  can  then  be  expedited  by 
performing  a  word-wise  logical  AND  on  bitmap  pairs 
to  detect  any  overlaps.  Since  WAIT-X  uses  prospec¬ 
tive  validation,  only  the  readset  of  a  potential  conflic- 
tor  need  be  compared  to  the  writeset  of  the  valida¬ 
tor:  the  potential  conflictor  is  still  running  so  none 
of  its  writes  are  visible  to  the  validator.  Prospective 
\'alidation’s  conflict  detection  is  simple  and  relatively 
low-cost,  but  it  can  be  improved  upon.  A  method 
to  augment  WAIT-X(S)’s  conflict  detection  scheme  is 
discussed  in  a  later  section. 

When  the  CCMgr  computes  the  conflict  set  for 
a  given  validator,  it  tallies  CHP  and  CLP  transac¬ 
tions.  To  determine  the  priority  of  a  conflictor  rela¬ 
tive  to  the  validator,  the  CCMgr  employs  a  function 
of  transaction  priorities  (using  RT-Mach’s  own  data 
type,  rt-priority.t)  which  returns  TRUE  if  the  first 
transaction  is  of  higher  priority  than  the  second.  Note 
that  this  function  is  the  same  one  employed  to  en¬ 
sure  transactions  retry  validation  in  priority  order,  but 
StarBzLse  ensures  at  compile  time  that  it  is  consistent 
with  the  CPU  scheduling  regime  under  which  Star- 
Base  is  configured  to  run.  Once  the  CHP  and  CLP 
have  been  determined,  the  CCMgr  decides  whether 
the  validator  can  commit  or  must  remain  on  the  wait¬ 
ing  list.  If  the  validator  commits,  the  CCMgr  sched¬ 
ules  aborts  for  transactions  in  the  validator’s  conflict 


set. 

The  wait  state  itself  is  implemented  by  associat¬ 
ing  an  RT-Mach  real-time  condition  variable  appropri¬ 
ately  called  waiting  with  each  transaction.  When  the 
CCMgr  decides  that  a  validating  transaction  should 
wait,  the  transaction  manager  is  enqueued  on  a  queue 
of  other  waiting  transactions  and  suspended  on  its 
condition  variable.  This  in  turn  releases  the  CCMgr 
monitor  lock  and  allows  other  transaction  managers 
to  use  CCMgr  services.  The  suspended  transaction 
manager  is  subsequently  resumed  when  another  trans¬ 
action  manager  calls  into  the  CCMgr  to  validate  or 
abort.  At  that  point  all  transactions  in  the  wait 
queue  axe  retried  individually  in  priority  order  and  if 
the  CCMgr  decides  that  one  in  particular  commits  or 
aborts,  it  signals  the  corresponding  waiting  condition 
variable,  unblocking  the  formerly  suspended  transac¬ 
tion  manager. 

4.3  Precise  Serialization 

Precise  serialization  is  a  conflict-detection  scheme 
for  optimistic  concurrency  control  [6].  The  goal  of 
precise  serialization  is  to  identify  transaction  con¬ 
flicts  which  strict  prospective  conflict  detection  con¬ 
siders  irreconcilable  but  can  actually  be  resolved  with¬ 
out  aborting  the  transactions  involved.  StarBase  re¬ 
places  the  prospective  conflict  detection  portion  of  the 
\VAIT-X(S)  scheme  with  Precise  Serialization  so  that 
WAIT-X(S)  can  still  enforce  transaction  serializability 
while  incurring  fewer  transaction  aborts  and  decreas¬ 
ing  the  likelihood  of  missing  transaction  deadlines. 

In  particular,  Lee  identified  the  case  where  a  \'alida- 
tor,  Tv^  attempts  to  commit  and  write  a  data  item  x 
which  another  uncommitted  transaction  Tcr  has  read 
but  not  ^vTitten.  Lee  terms  data  conflicts  of  this  type 
write-read  conflicts.  As  mentioned  previously,  strict 
prospective  \^idation  checks  the  writeset  of  the  val¬ 
idator  against  the  readset  of  its  potential  conflictors, 
identifying  write-read  conflicts.  If  it  detects  such  a 
conflict,  the  resolution  requires  aborting  some  of  the 
conflicting  transactions.  Note,  however,  that  if  Tcr 
were  to  commit  first,  there  would  be  no  conflict  on 
data  item  x.  Haritsa  noticed  the  same  problem  aind 
describes  part  of  the  rationale  behind  the  priority  wait 
scheme  of  WAIT-X  as  a  passive  attempt  to  induce 
transactions  to  reserialize  themselves  in  a  nonconflict¬ 
ing  order.  Lee’s  Precise  Serialization  takes  a  more 
deterministic  tack:  it  allows  Ty  to  commit  while  Tcr 
is  still  running,  but  requires  Tcr  to  behave  as  if  it  had 
committed  before  Ty-  Tcr  is  constrained  so  that  it 
cannot  read  any  data  item  written  by  Ty  because  it 
would  see  a  “future”  value,  and  it  cannot  write  any 


data  item  read  by  Ty  since  Ty  has  committed  and 
cannot  change  the  past.  Finally  Tcr  must  discard  (as 
late  writes)  updates  to  any  data  items  which  Ty  wrote 
during  its  commit.  This  pseudo-reserialization  of  Ty 
and  Tcr  is  called  backward  ordering  and  its  goal  is  to 
increase  the  probability  that  potential  conflictors  can 
complete  without  either  aborting  and  restarting. 

4.4  Precise  Serialization  Implementation 

Since  Precise  Serialization  is  a  conflict-detection 
scheme,  not  a  full-blown  method  of  concurrency  con¬ 
trol,  it  supplements  StarBase’s  WAIT-X  implementa¬ 
tion  rather  than  replacing  it  entirely.  Precise  Serial¬ 
ization  modifies  the  WAIT-X  validation  conflict  de¬ 
tection  and  requires  the  addition  of  a  mechanism  to 
detect  when  a  pseudo-reserialized  transaction  does  not 
behave  in  accordance  with  its  virtual  order  in  the  ex¬ 
ecution  history. 

During  validation,  Precise  Serialization  partitions 
the  set  of  conflicting  transactions  into  those  which  con¬ 
flict  reconcilably  and  those  which  conflict  irreconcil¬ 
ably.  Should  the  validator  be  allowed  to  commit,  the 
reconcilable  conflictors  must  be  pseudo-reserialized  by 
backward  ordering,  while  the  irreconcilable  conflictors 
must  be  aborted.  To  keep  track  of  which  are  which, 
StarBase  maintains  a  reserialization  candidate  set  for 
the  validator  in  addition  to  the  conflict  set  of  the 
WAIT-X  implementation  described  previously.  The 
conflict  set  still  identifies  which  transactions  conflict 
irreconcilably  with  the  validator,  but  the  candidate  set 
identifies  precisely  those  datasets  among  which  recon¬ 
cilable  write-read  conflicts  exist. 

To  construct  the  candidate  set  and  the  conflict  set 
at  the  point  of  validation,  the  CCMgr  cycles  through 
each  dataset  referenced  by  the  validator,  Ty.  If  Ty 
has  only  a  write-read  conflict  with  an  uncommitted 
transaction,  Tcr,  on  a  dataset,  then  the  serialization 
order  should  be  Tcr  Ty  (backward  validation) 
and  the  conflicting  datasets  are  added  to  the  reseri¬ 
alization  candidate  set.  If  Tcr  has  only  a  write-read 
conflict  with  Ty,  then  the  serialization  order  should 
be  Ty  Tcr  (forward  validation).  In  this  case  Ty 
and  Tcr  are  considered  to  be  non-conflicting.  If  the 
CCMgr  determines  that  the  serialization  order  should 
be  simultaneously  Tcr  Ty  and  Ty  ^  Tcr,  then 
Ty  and  Tcr  are  irreconcilably  conflicting,  and  Tcr 
is  added  to  the  conflict  set.  Note  that  the  CCMgr 
does  not  consider  write-write  conflicts  since  transac¬ 
tions  are  required  to  read  tuples  to  determine  their  val¬ 
ues  or  to  establish  that  they  are  empty  before  writing 
them.  Consequently  a  writeset  is  always  a  subset  of 
the  readset  (for  a  given  transaction  and  relation)  and 


checking  both  against  a  potential  conflictor’s  writeset 
is  redundant. 

Once  the  candidate  set  and  conflict  set  are  com¬ 
pletely  identified,  the  CCMgr  determines  whether 
the  validator  should  commit  or  wait  according  to 
the  WAIT-X  commit  test.  If  the  validator  waits, 
the  conflict  and  candidate  sets  are  discarded-they 
will  be  recomputed  if  and  when  the  validator  retries 
validation.  If  the  validator  commits,  the  transac¬ 
tions  in  the  conflict  set  are  aborted  and  the  CCMgr 
must  pseudo-reserialize  the  reconcilable  conflictors. 
Pseudo-reserialization  is  achieved  by  attaching  copies 
(or  remnants)  of  Tv’s  datasets  to  those  datasets  with 
which  they  conflict.  Note  that  these  dataset  pairs  are 
precisely  those  comprising  the  reserialization  candi¬ 
date  set.  Thus  when  a  conflictor  later  updates  its  read- 
and  writesets,  it  can  quickly  check  whether  the  opera¬ 
tion  \dolates  its  virtual  order  in  the  execution  history 
by  consulting  the  dataset  remnants  attached  to  the 
dataset  involved  in  the  operation. 

Since  one  of  Ty^s  datasets  may  conflict  with  more 
than  one  of  the  conflictors’,  a  remnant  is  given  a  refer¬ 
ence  count  rather  than  physically  copied.  As  conflic¬ 
tors  commit  or  abort  one  by  one,  the  CCMgr  decre¬ 
ments  the  reference  count.  When  the  last  conflictor 
terminates,  the  CCMgr  discards  Tk’s  dataset  rem¬ 
nant. 

In  the  same  token  several  transactions  may  commit 
even  though  they  conflict  with  a  particular  transac¬ 
tion,  Tqr.  The  dataset  remnants  of  these  transactions 
attached  to  Tcr  are  collectively  known  as  the  recently 
committed  conflicting  datasets  (or  RGCs),  Pseudo- 
reserialized  transactions  such  as  Tcr  must  check  each 
remnant  in  the  RCCs  for  a  given  dataset  whenever 
they  read  or  write  to  that  dataset.  As  previously  men¬ 
tioned,  Tcr  cannot  read  anything  marked  as  written 
in  its  RCCs,  since  it  would  read  a  “future”  value.  In 
most  cases  Tcr  cannot  write  anylihing  marked  as  read 
in  its  RCCs,  since  it  would  write  a  “past”  value.  The 
exception  occurs  when  Tcr  writes  a  data  item  that 
Ty  has  also  written,  in  which  case  Ten’s  write  is  dis¬ 
carded  as  a  late  write.  The  net  result  is  that  only  the 
value  that  Ty  wrote  is  visible,  consistent  with  the  ex¬ 
ecution  history  Tcr  Ty,  Unfortunately  StaxBase’s 
update  operation  may  use  past  values  to  compute  new 
ones,  precluding  the  use  of  late  writes  for  it.  The  only 
situation  in  which  the  late  write  phenomenon  can  be 
used  is  one  in  which  the  reserialized  operation  is  sup¬ 
posed  to  have  been  performed  before  a  delete.  Since 
delete  is  idempotent,  the  reserialized  operation  can  be 
correctly  discarded. 


5  Enforcing  Time  Constraints 

Each  StaxBase  transaction  is  accompanied  by  a 
deadline  specification.  Since  StarBase  is  a  firm  RT- 
DBMS,  it  attempts  to  process  the  transaction  and 
reply  to  the  application  at  or  before  this  firm  dead¬ 
line]  no  processing  should  occur  after  the  deadline. 
Firm  deadline  transactions  may  be  contrasted  with 
soft  deadline  transactions  which  are  viewed  as  having 
some  usefulness  even  if  their  execution  extends  be¬ 
yond  the  deadline  point.  Hard  deadline  transactions 
are  those  transactions  whose  failure  to  execute  on  time 
is  viewed  as  catastrophic. 

5.1  Deadline  Management 

The  first  step  in  enforcing  firm  deadlines  is  de¬ 
tecting  exactly  when  the  deadline  expires.  As  with 
other  real-time  functionalitjs  StarBase  relies  heavily 
on  the  RT-Mach  operating  system  to  provide  support¬ 
ing  mechanisms.  RT-Mach  provides  the  concept  of  a 
real-time  deadline  handler,  a  separate  thread  of  execu¬ 
tion  which  performs  application-specific  actions  when 
the  deadline  expires.  Typical  actions  are  to  abort  the 
thread  (firm  deadline)  or  lower  its  priority  (soft  dead¬ 
line).  In  addition  to  RT-Mach’s  real-time  threads, 
implementation  of  a  deadline  handler  requires  time- 
based  synchronization.  In  order  to  ensure  the  han¬ 
dler  action  is  ready  to  execute  before  the  deadline, 
the  real-time  deadline  handler  must  be  eagerly  allo¬ 
cated  as  a  real-time  thread  to  execute  the  deadline 
handler  code.  The  deadline  handler  thread  then  uses 
a  real-time  timer  to  block  the  thread  imtil  the  dead¬ 
line  expires.  A  real-time  timer  is  an  RT-Mach  ab¬ 
straction  which  allows  real-time  threads  to  synchro¬ 
nize  with  particular  points  in  time  as  measured  by 
real-time  clock  hardware  de\'ices  [8]. 

RT-Mach  provides  a  default  deadline  handler  con¬ 
structed  from  the  building  blocks  discussed  above,  but 
it  is  inadequate  for  StarBase ’s  purposes.  First,  the  de¬ 
fault  deadline  handler  supports  only  threads  with  uni¬ 
form  deadlines.  StarBase,  since  it  assumes  no  a  priori 
information  about  its  transaction  workload,  requires 
that  its  deadline  handlers  adapt  to  new  transactions 
and  their  deadlines  as  they  enter  service.  Secondly,  a 
RT-Mach  default  deadline  handier  forcibly  suspends  a 
thread  when  it  misses  its  deadline  so  that  the  thread 
does  not  interfere  with  the  handler’s  execution.  If  a 
thread  misses  its  deadline  while  in  the  middle  of  a  crit¬ 
ical  section,  it  is  suspended  and  cannot  leave  the  criti¬ 
cal  section  imtil  it  is  resumed.  StarBase  uses  a  critical 
section  to  resolve  potential  race  conditions  between 
transaction  commit  (by  the  transaction  manager)  and 


deadline  abort  (by  the  deadline  manager),  so  use  of 
a  RT-Mach-style  deadline  handler  can  result  in  dead¬ 
lock.  Thirdly,  default  deadline  handlers  do  not  allow 
the  transaction  and  deadline  managers  to  synchronize 
cooperatively.  A  deadline  manager  must  know  when 
a  transaction  completes  so  that  it  does  not  generate  a 
useless  abort;  a  transaction  manager  must  know  when 
the  deadline  expires,  so  that  it  does  not  commit  the 
aborted  transaction.  Neither  is  possible  without  some 
shared  state  which  must  be  accessed  in  mutual  exclu¬ 
sion. 

5,2  Deadline  Management  Implementa¬ 
tion 

The  solution,  then,  is  to  devise  a  deadline  han¬ 
dler  implementation  which  handles  variable  deadlines, 
avoids  potential  deadlocks,  and  is  eagerly  allocated  to 
provide  some  degree  of  predictability  but  at  the  same 
time  takes  precedence  over  the  transaction  it  manages 
when  the  transaction  deadline  expires. 

As  mentioned  in  Section  3,  RT-Mach  provides  real¬ 
time  thread  synchronization  facilities.  Each  trans¬ 
action  and  deadline  manager  pair  can  be  synchro¬ 
nized  using  RT-Sync  to  construct  a  monitor  with  two 
real-time  condition  \^iables,  newTransaction  and 
dmgr Cancel.  The  transaction  manager  must  be  sure 
that  the  deadline  manager  is  ready  to  enforce  a  new 
deadline  before  a  new  transaction  arrives,  and  the 
deadline  manager  must  be  sure  the  transaction  man¬ 
ager  has  received  a  new  transaction  before  it  prepares 
for  the  new  deadline  expiration.  The  condition  \OTi- 
able  newTransaction  is  used  both  to  wait  when  one  of 
the  managers  lags  behind  the  other  and  to  signal  the 
arrival  of  a  new  transaction  to  the  deadline  manager. 

The  condition  variable  dmgr  Cancel  is  used  much 
differently.  The  deadline  manager  must  simultane¬ 
ously  block  waiting  for  the  deadline  to  expire  or  to 
be  cancelled  by  the  transaction  manager,  whichever 
comes  first.  Since  RT-Mach  provides  a  time-out  on 
its  real-time  condition  variables,  the  deadline  manager 
need  only  wait  on  dmgr  Cancel,  providing  the  deadline 
as  the  time-out  value,  to  block  until  the  deadline.  Fur¬ 
thermore,  should  the  transaction  manager  complete 
the  transaction,  it  can  cancel  the  deadline  manager 
by  signalling  on  dmgrCancel. 

The  transaction  and  deadline  manager  behaviors 
are  presented  in  Figures  3  and  4.  This  solution  allows 
the  deadline  handler  to  deal  with  deadlines  which  vary 
from  transaction  to  transaction  since  the  transaction 
and  deadline  managers  synchronize  before  a  transac¬ 
tion  enters  service.  The  use  of  a  monitor  to  synchro¬ 
nize  the  transaction  and  deadline  managers  also  avoids 


rt_mutex_t 
rt  _c  ondit  ion.t; 
message^t 
boolean_t 


monitorLock; 
newTransaction ; 
request; 

tmgrReady  -  FALSE; 


while  (TRUE) 

< 

rt_mutex_lock  (monitorLock,  NULL); 
tmgrReady  =  TRUE; 
if  (dmgrReady  ==  FALSE) 

i 

if  (dmgr Armed) 

rt_condition_ signal  (dmgrCancel) ; 
rt_condition_wait  (newTransaction,  NULL); 

} 

mach_msg_receive  (request) ; 
rt_condition_signal  (newTransaction) ; 
tmgrReady  -  FALSE; 
rt_mutex_unlock  (monitorLock) ; 

/*  execute  transaction  */ 


Figure  3:  Transaction  Manager 


the  deadlock  possible  were  the  deadline  manager  capa¬ 
ble  of  explicitly  suspending  the  transaction  manager. 
Another  implementation  of  the  deadline  handler  in¬ 
volves  creating  and  destroying  the  deadline  manager 
at  the  beginning  and  end  of  each  transaction.  Eagerly 
allocating  the  deadline  manager  thread,  however,  re¬ 
duces  the  amount  of  variability  in  transaction  service 
times,  providing  an  increased  degree  of  predictability. 

Finally,  the  easiest  goal  to  achieve  is  that  of  the 
deadline  manager  taking  precedence  over  its  trans¬ 
action  manager.  Since  the  deadline  handler’s  exe¬ 
cution  is  considered  more  critical  than  the  transac¬ 
tion’s  when  the  deadline  expires,  the  deadline  handler 
should  be  assigned  a  higher  priority  so  that  RT-Mach 
gives  it  preferential  scheduling  relative  to  the  trans¬ 
action  whose  deadline  it  handles.  At  the  same  time, 
the  execution  of  the  deadline  handler  should  not  cause 
priority  inversion  by  interfering  with  the  transaction 
managers  of  higher  priority  transactions.  In  order  for 
the  deadline  handler  to  function  as  desired,  it  should 
have  a  slightly  higher  criticality  and  slightly  tighter 
timing  constraints  than  its  corresponding  transaction 
manager,  but  a  lower  criticality  and  looser  timing  con¬ 
straints  than  transaction  managers  for  higher  priority 
transactions. 

Fortunately,  the  criticality  and  time  spaces  are  both 
very  large  in  RT-Mach  (at  least  2^  where  n  is  the  num¬ 
ber  of  bits  in  a  word).  Furthermore,  real-time  CPU 
and  resource  scheduling  generally  make  decisions  on 


rt_condition_t  dmgrCaincel; 
boolean^t  dmgrArmed  =  FALSE; 

booleaii_t  dmgrReady  =  FALSE; 

rtjautex^lock  (monitorLock,  NULL) ; 
while  (TRUE) 

if  (tmgrReady) 

rt_condition_sigiial  (newTransaction)  ; 
dmgrReady  =  TRUE; 

rt_condition_wait  (newTransaction,  NULL); 
dmgrReady  =  FALSE; 
dmgrArmed  =  TRUE; 
status  = 

rt_condition_wait  (dmgrCancel , 

request .deadline) ; 

dmgrArmed  =  FALSE; 
if  (status  ==  KERN.SUCCESS) 
continue; 

/♦  abort  transaction  ♦/ 
rt_mutex_lock  (monitorLock) ; 

} 

Figure  4;  Deadline  Manager 
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Figure  5:  Thread  Priority  Assignments 


which  thread  to  run  by  simply  comparing  priorities 
without  quantifying  how  much  they  dififer.  The  large 
priority  space  and  the  qualitative  priority  comparisons 
allow  StmBase  to  map  the  external  transaction  prior¬ 
ities  onto  new  priorities  at  which  the  transaction  and 
deadline  manager  real-time  threads  actually  run. 

The  RT-Mach  criticality  priority  space  consists  of 
unsigned  integers,  with  0  being  the  highest  criticality 
and  2”  “  1  being  the  lowest.  The  transaction  and  dead¬ 
line  manager  thread  criticalities  supplied  to  RT-Mach 
are  gotten  by  doubling  the  external  transaction  prior¬ 
ity  and  adding  one  to  the  transaction  manager  criti¬ 
cality.  A  deadline  manager  thus  always  has  a  greater 
criticality  than  its  own  transaction  manager  thread 
but  has  a  lesser  criticality  than  that  of  the  next  high¬ 
est  criticality  transaction,  as  illustrated  in  Figure  5. 


Although  time  is  viewed  as  continuous  and  real¬ 
valued,  RT-Maeh’s  ability  to  measure  it  is  limited  by 
its  clock  hardware  resolution.  RT-Mach,  therefore, 
maintains  a  data  type  which  represents  discretized 
time  in  terms  of  nanoseconds,  though  its  clocks  mea¬ 
sure  time  with  significantly  lower  precision.  Tighter 
timing  constraints  for  the  deadline  manager  are  gotten 
by  adding  one  nanosecond  to  each  timing  constraint 
of  the  corresponding  transaction  manager.  Thus  while 
the  timing  constraints  for  the  transaction  and  deadline 
manager  threads  are  not  appreciably  different  as  mea¬ 
sured  by  the  hardware  clock,  scheduling  regimes  such 
as  Earliest  Deadline  First  will  still  schedule  the  dead¬ 
line  manager  in  preference  to  the  transaction  manager. 

5.3  Asynchronous  Aborts 

As  previously  discussed,  firm  deadlines  are  handled 
asynchronously  by  a  deadline  handler  which  is  charged 
with  aborting  the  thread  in  question.  In  StarBase,  the 
asynchrony  between  transaction  and  deadline  man¬ 
agers  results  in  a  race  condition  between  the  com¬ 
mit,  and  deadline  abort  of  a  transaction.  The  concur¬ 
rency  controller  (CCMgr)  is  the  authority  which  per¬ 
mits  a  transaction  to  commit  and  the  commit/abort 
contention  is  resolved  through  it.  As  described  in  Sec¬ 
tion  4,  the  CCMgr  is  a  monitor  and  threads  execut¬ 
ing  inside  of  it  are  capable  of  atomically  determining 
whether  a  transaction  is  in  the  process  of  committing 
or  not. 

When  the  deadline  expires  and  the  deadline  man¬ 
ager  must  abort  the  transaction,  it  calls  into  the 
CCMgr.  If  the  transaction  has  not  yet  committed, 
the  CCMgr  marks  the  transaction  as  aborted  and  dis¬ 
allows  it  as  a  potential  conflictor  with  other  validators 
by  unlinking  it  from  CCMgr  internal  data  structures. 
How  the  CCMgr  subsequently  notifies  the  transaction 
manager  of  the  abort  depends  on  the  state  of  the  trans¬ 
action.  E  the  transaction  has  not  yet  entered  valida¬ 
tion,  the  transaction  manager  is  notified  the  next  time 
it  updates  its  read-  or  writesets;  if  the  transaction  has 
entered  validation  (i.e.,  entered  the  wait  state),  the 
CCMgr  resumes  the  transaction  manager  according  to 
the  mechanism  described  in  Section  4  with  the  status 
that  it  has  failed  validation. 

In  addition  to  the  race  condition  between  the  com¬ 
mit  and  abort  of  a  transaction,  there  is  another  race 
condition  between  simultaneous  aborts.  For  example, 
a  transaction  may  discover  a  semantic  error  (e.g.,  re¬ 
lation  not  foimd)  near  the  point  where  the  deadline 
expires  or  a  transaction  may  abort  due  to  conflicts 
during  validation.  Because  of  the  different  natures 
of  these  aborts,  different  actions  are  required  on  the 


part  of  StarBase.  The  CCMgr  again  cirbitrates  which 
one  of  multiple  aborts  takes  precedence.  The  most 
important  is  the  deadline  abort  which  supersedes  all 
other  aborts  in  order  to  expedite  replying  to  the  client. 
Semantic  errors  are  next  in  line  and  conflict  aborts 
are  least  critical.  Aborts  due  to  deadline  expiration 
and  semantic  errors  must  prevail  over  conflict  aborts, 
since  the  former  require  discarding  transactions  per¬ 
manently  whereas  the  latter  result  in  restarting  trans¬ 
actions. 

As  described  in  Section  4,  all  validating  transac¬ 
tions  axe  retried  whenever  a  transaction  enters  valida¬ 
tion  for  the  first  time  or  aborts.  Since  retrying  val¬ 
idation  may  result  in  multiple  transactions  commit¬ 
ting  or  aborting,  it  may  be  a  fairly  lengthy  process. 
Rather  than  allowing  a  deadline  manager’s  call  into 
the  CCMgr  monitor  to  block  it  for  such  a  long  period 
of  time,  the  CCMgr  maintains  a  thread  which  acts  as 
a  proxy.  When  a  deadline  manager  requests  that  the 
CCMgr  abort  its  transaction,  the  deadline  manager 
simply  hands  off  the  appropriate  priority  to  the  proxy 
thread  and  then  signals  it.  The  deadline  manager  is 
then  free  to  leave  the  CCMgr  monitor  and  reply  to 
the  client  while  the  proxy  retries  all  waiting  validators. 
Note  that  the  deadline  manager  assigns  the  priority  of 
the  transaction  manager  rather  than  its  own  priority 
to  the  proxy  so  that  the  deadline  manager  can  proceed 
unhindered. 


6  Conclusions 

This  paper  details  the  architecture  to  support  a  firm 
RT-DBMS  assuming  no  a  priori  knowledge  of  transac¬ 
tion  workload  characteristics.  Unlike  previous  simula¬ 
tion  studies,  StarBase  uses  a  real-time  operating  sys¬ 
tem  to  provide  basic  real-time  functionality  and  deals 
with  issues  beyond  transaction  scheduling:  resource 
contention,  data  contention,  and  enforcing  deadlines. 
Issues  of  resource  contention  are  dealt  with  by  employ¬ 
ing  priority-based  CPU  and  resource  scheduling  pro¬ 
vided  by  the  underlying  real-time  operating  system. 
Issues  of  data  contention  are  dealt  with  by  use  of  a 
priority-cognizant  concurrency  control  algorithm  with 
a  special  conflict-detection  scheme,  called  Precise  Se¬ 
rialization,  to  reduce  the  number  of  aborts.  Issues  of 
deadline-handling  are  dealt  with  by  constructing  dead¬ 
line  handlers  which  synchronize  with  the  start  and  end 
of  a  transaction  and  which  don’t  interfere  with  its  ex¬ 
ecution  until  the  deadline  expires. 

The  next  step  is  to  extend  these  solutions  to  the 
situation  in  which  transaction  characteristics  are  at 


least  partially  specified  beforehand.  With  prior  knowl¬ 
edge,  a  RT-DBMS  can  preallocate  resources  and  ar¬ 
range  transaction  schedules  to  minimize  conflicts,  re¬ 
sulting  in  more  predictable  service.  Execution  time 
estimates  and  off-line  analysis  can  be  used  to  increase 
DBMS- wide  predictability.  Temporal  consistency  [4], 
where  data  used  to  derive  new  data  must  be  consis¬ 
tent  within  a  certain  validity  interval,  is  also  a  matter 
to  be  explored.  Once  the  basic,  real-time,  P0SIX.4- 
compliant  functionality  needed  to  support  a  firm  real¬ 
time  database  has  been  established,  StarBase  can  be 
ported  to  other  platforms. 
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